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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Security  Special  Interest  Group 
(SECSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW)  hosted  by  the  National 
Institute  of  Standards  and  Technology  (NIST).  See  Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  There  is  significant  technical  change  from  this  text  as 
previously  given. 

Future  changes  and  additions  to  this  version  of  these  I mplementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  12  -  Security 

Editor's  Note  -  Previous  material  in  this  part  has  been  deleted  and  is  no  longer  applicable. 

0  Introduction 

The  relationship  between  protocols  and  security  Is  accomplished  by  developing  a  security  profile  that  binds 
these  two  together.  Security  profiles  define  protocol  specific  implennentations  of  security  architectures. 

A  security  profile  includes  the  following  items: 

a)  A  grouping  of  the  security  services  to  be  offered; 

b)  The  placement  of  those  security  services; 

c)  The  selection  of  mechanisms  to  support  the  placed  security  services. 

This  part  completes  this  sequence  of  steps  for  several  generalized  security  architectures.  A  generalized 
security  architecture  is  chosen  and  tailored  to  derive  a  protocol-specific  security  profile.  This  part  is 
comprised  of  protocol-specific  security  profiles  and  other  supporting  functions. 

1  Scope 

2  Normative  References 

[IS07498-2]     ISO/IEC  7498-2  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Reference  Model  -  Part  2:  Security  Architecture,  February  1989. 

[IS08649]       I  SO/I  EC  8649: 1 988/QAGPmi  1 :1990  Service  Definition  for  the  Association  Control  Service 
Element,  Addondumfynenchrtent  1:  Peer  Entity  Authentication  During  Association  Establishment. 

[ISO8650]        ISO/IEC  9594-3  Information  Technology  -  Open  Systems  Interconnection  -  The  Directory 
-  Part  3:  Abstract  Service  Definition. 

[ISO8650/1]     ISO/IEC  8650:  1988/OADAmd  1;t990  Protocol  Specification  for  the  Association  Control 
Service  Element,  Amendment  1:  Peer  Entity  Authentication  During  Association  Establishment. 

[IS09594-7]     ISO/IEC  9594-7  Information  Processing  Systems  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  7:  Selected  Object  Classes,  1990. 

[IS09594-8]     ISO/IEC  9594-8  Information  Processing  Systems  -  Open  Systems  Interconnection  -  The 
Directory  -  Part  8:  Authentication  Framework,  1990. 

[ISO10021-4]    ISO/IEC  10021-4  Information  Processing  Systems  -  Text  Communication  -  MOTIS  - 
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Message  Transfer  System  :  Abstract  Service  Definition  and  Procedures. 
[X.509-88]       CCITT  X.509:1988  Ttie  Directory  -  Autiientication  Frameworli. 
[X.51 1-88]       CCITT  X.51 1 : 1 988  Tfie  Directory  -  Abstract  Sen/ice  Definition. 
p(.41 1-84]       CCITT  X.41 1 :1984  Message  Transfer  System  -  Message  Transfer  Layer. 
[X.521-88]       CCITT  X.521 :1988  Ttie  Directory  -  Selected  Object  Classes. 

3  Definitions 

4  Symbols  and  Abbreviations 

5  Architectures 

Editor's  Note  -  The  proposed  text  for  this  clause  appears  in  WIA  Part  12,  clause  5. 

5.1  Introduction 

5.2  General  OIW  Application  Environments 

5.3  Security  Classes 

5.4  Guidelines  for  OIW  Application  Profile  Development 


2 


PART  12  -  SECURITY 


September  1992  (Stable) 


6     Key  Management 

[IS07498-2]  defines  Key  Management  (KM)  as  the  "generation,  storage,  distribution,  deietion,  arcliiving,  and 
application  of  keys  in  accordance  witli  a  security  policy."  Tlie  Security  SIG  recognizes  tliat  security  policies 
are  outside  the  scope  of  lAs,  and  it  is  Inappropriate  to  make  general  recommendations  in  the  absence  of 
a  KM  framework. 


7    Security  Algorithms 

Editor's  Note  -  Implementors  are  cautioned  that  security  of  an  algorithm  may  change  at  any  time.  Therefore, 
the  WIA  must  be  consulted  in  order  to  determine  if  there  is  more  current  information. 

The  algorithms  Included  here  are  listed  in  no  particular  order.  It  is  beyond  the  scope  of  these  agreements 
to  recommend  the  use  of  one  algorithm  over  another.  However,  if  a  vulnerability  is  known  to  exist  a 
reference  will  be  provided  along  with  a  recommendation  not  to  use  the  algorithm. 

This  clause  references  a  definitive  specification  for  each  algorithm,  which  includes  an  object  identifier.  In 
general,  control  of  the  definitive  specification  is  expected  to  be  outside  the  scope  of  the  OIW.  The  benefit 
of  not  controlling  the  specification  is  that  the  organization  that  developed  the  algorithm  is  best  situated  to 
maintain  and  have  knowledge  of  the  security  of  the  algorithm.  Algorithms  for  which  there  is  no  controlling 
organization  are  defined  in  an  Annex  in  this  Part. 

For  each  algorithm,  its  typical  usage  is  stated,  its  definitive  reference  is  given,  and  its  object  identifier  is 
included  for  reference  purposes.Optionally,  additional  information  may  be  included,  for  example  a  reference 
to  known  vulnerabilities. 

Editor's  Note  -  Some  of  the  references  are  RFCs,  Internet  Drafts,  and  PKCS  documents.  We  need  to  include 
information  on  how  to  access  these  documents. 


7.1  Square-Mod-N 

Square-Mod-N  is  a  hash  algorithm  that  is  used  to  compute  a  fixed  size  representation  of  an  input  stream. 
It  is  defined  in  [X.509]  and  its  object  identifier  is  defined  there  as: 

sqMod-n  ALGORITHM 
PARAMETER  BlockSize 
::=  {hashAlgorithm  1} 

BlockSize  ::=  INTEGER 

Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D  of  [X.509]  has 
revealed  that  the  function  is  not  secure.  Its  use,  therefore,  is  discouraged. 


Editor's  Note  -  We  need  the  reference  that  identifies  its  vulnerabilities  so  we  can  recommend  it  not  be  used. 
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7.2      Message  Digests 

These  message  digest  algorithms  (or  hash  algorithms)  compute  a  fixed  size  representation  of  an  input 
stream.  They  have  different  performance  characteristics  and  employ  different  computational  techniques, 
making  each  suitable  for  different  applications. 


7.2.1  MD2 

MD2  Is  a  message  digest  algorithm  that  employs  accepted,  traditional  computational  techniques.  Its  speed 
Is  the  slowest  of  the  message  digests  listed  here. 

It  Is  defined  in  Internet  Draft  [a]  and  its  object  Identifier  is  defined  there  as: 

md2  ALGORITHM 
PARAMETER  NULL 

{iso(l)  meinber-body( 2 )  US(840)  rsadsi  (113549)  digestAlgorithin(2)  2} 

Editor's  Note  -  There  is  a  Directory  SIG  OlD  for  this  algorithm. 

The  reference  includes  a  source  code  Implementation  of  the  algorithm  written  in  the  C  programming 
language.  MD2  is  copyrighted  and  its  use  may  require  specific  permission  or  a  license.  Details  are  stated 
In  the  Internet  Draft. 


7.2.2  MD4 

MD4  Is  a  message  digest  algorithm  that  employs  non-traditional  computational  techniques  to  enhance  its 
speed  in  software  and  hardware  with  native  32-blt  arithmetic.  Its  speed  Is  the  fastest  of  the  message  digests 
listed  here. 

It  Is  defined  in  Internet  Draft  [b]  and  its  object  Identifier  is  there  as: 

ind4  ALGORITHM 
PARAMETER  NULL 

::=  {lso(1)  member-body(2)  US(840)  rsadsl(1 13549)  dlgestAlgorithm(2)  4} 


This  reference  includes  a  source  code  implementation  of  the  algorithm  written  in  the  C  programming 
language. 

It  Is  suggested  that  MD4  be  used  only  with  applications  for  which  performance  Is  critical. 

Editor's  Note  -  We  need  to  include  text  from  the  MD4/5  Internet  Drafts  which  describes  the  differences 
between  the  two  algorithms  and  the  preference  for  MD5. 
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MD5  is  a  message  digest  algorithm  that  employs  traditional  computational  techniques  with  the  speed 
enhancements  of  MD4. 

It  is  defined  in  Internet  Draft  [c]  and  its  object  identifier  is  defined  there  as: 

mdS  ALGORITHM 
PARAMETER  NULL 

::=  {iso(1)  member-body(2)  US(840)  rsadsi(1 13549)  digestAlgorithm(2)  5} 


This  reference  includes  a  source  code  implementation  of  the  algorithm  written  in  the  C  programming 
language. 


7.3  RSA 

RSA  is  a  public  key  (asymmetric)  cryptographic  algorithm,  typically  used  in  conjunction  with  message  digest 
(or  hash)  algorithms  to  create  digital  signatures  and  for  confidential  distribution  of  symmetric  keys.  It  may 
also  be  used  to  exchange  confidential  messages. 

The  RSA  algorithm  is  defined  in  [d]  and  is  also  described  in  Annex  C  of  [X.509].  The  RSA  technology  is 
patented  in  the  United  States  [e][f]. 

Editor's  Note  -  Explain  why  there  are  two  definitions. 


7.3.1        RSA  Definition 

RSA  is  defined  in  [X.509]  and  its  object  identifier  is  defined  there  as: 


rsa  ALGORITHM 

PARAMETER  KeySize 

::=  {encryptionAlgorithm  1} 

KeySize  ::=  INTEGER 

The  key  size  specifies  the  length  in  bits  of  the  RSA  public  key  modulus. 


7.3.2       RSA  Encryption 

RSA  Encryption  is  defined  in  PKCS  #1  [g]  and  its  object  identifier  is  defined  there  as: 
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rsaEncryption  ALGORITHM 
PARAMETER  NULL 

::=  {iso(l)  member-body ( 2 )  US(840)  rsadsi ( 113549 )  pkcs(l)  pkcs-l(l)  l) 


Square-Mod-N  is  a  signature  algoritlim  that  combines  tlie  Square-Mod-N  hasli  algorithim  witfi  thie  RSA 
ct7ptograplnic  algoritlim  to  produce  a  digital  signature.  This  algorithm  is  defined  in  [X.509]  and  its  object 
identifier  is  defined  there  as: 

sqMod-nWi thRSA  ALGORITHM 
PARAMETER  KeyAndBlockSi ze 
::=  {signatureAlgor ithm  l} 

KeyAndBlockSi ze  ::=  INTEGER 

Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D  of  [X.509]  has 
revealed  that  the  function  is  not  secure.  Its  use,  therefore,  is  discouraged. 


7.5      Message  Digests  with  RSA 

The  algorithms  listed  below  are  signature  algorithms  that  combine  a  message  digest  algorithm  with  the  RSA 
cryptographic  algorithm  to  produce  a  digital  signature. 

Editor's  Note  -  The  OlDs  below  have  been  assigned  by  the  Directory  SIG  and  the  Security  SIG.  Should  we 
explain  why  they  do  not  appear  in  a  single  tree? 


Its  object  identifier  is: 

md2WithRsa  ALGORITHM 

PARAMETER  NULL 

::=  {signatureAlgor ithm  1} 

Editor's  Note  -  This  OID  was  assigned  by  the  Directory  SIG. 


7.5.2        MD4  with  RSA 

Its  object  identifier  is: 

md4Wi thRSA  ALGORITHM 
PARAMETER  NULL 
: :=  {algorithm  2} 


7.4 


Square-Mod-N  with  RSA 


7.5.1 


MD2  with  RSA 
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7.5.3        MD5  with  RSA 

Its  object  identifier  Is: 

mdSWithRSA  ALGORITHM 
PARAMETER  NULL 
: :=  {algorithm  3} 


7.6      Message  Digests  with  RSA  Encryption 

The  algorithms  listed  below  are  signature  algorithnns  that  combine  a  message  digest  algorithm  with  the  RSA 
Encryption  cryptographic  algorithm  to  produce  a  digital  signature. 


7.6.1        MD2  with  RSA  Encryption 

MD2  with  RSA  encryption  is  defined  in  PKCS  #1  [g]  and  its  object  Identifier  Is  defined  there  as: 

ind2WithRSAEncryption  ALGORITHM 
PARAMETER  NULL 

::=  {iso(l)  member-body ( 2 )  US(840)  rsadsi ( 113549 )  pkcs(l)  pkcs-l(l)  2} 


7.6.2       MD4  with  RSA  Encryption 


Its  object  identifier  is: 

md4WithRSAEncryption  ALGORITHM 
PARAMETER  NULL 
: :=  {algorithm  4} 


7.6.3       MD5  with  RSA  Encryption 

MD5  with  RSA  Encryption  is  defined  in  PKCS  #1  [g]  and  Its  object  identifier  Is  defined  there  as: 

mdSWithRSAEncryption  ALGORITHM 
PARAMETER  NULL 

::=  {iso(l)  member-body ( 2 )  US (840)  rsadsi ( 113549 )  pkcs(l)  pkcs-l(l)  4} 
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7.7      Diffie-Hellman  Key  Exchange 

Diffie-Hellman  Key  Exchange  is  a  public  key  (asymmetric)  algoritlim  whereby  two  parties,  without  any  prior 
arrangements,  can  agree  upon  a  secret  l<ey.  This  l<ey  could  be  used,  for  example,  to  encrypt  further 
communications  between  the  parties. 

The  Diffie-Hellman  Key  Exchange  is  defined  in  [h]  and  is  also  described  in  [j].  The  Diffie-Hellman  Key 
Exchange  is  patented  in  the  United  States  [i][f]. 

The  object  identifier  is  defined  in  PKCS  #3  [j]  as: 

dhKeyAgreement  ALGORITHM 
PARAMETER  DHParameter 

::=  {iso(l)  ineinber-body( 2 )  US(840)  rsadsi  (113549)  pkcs(l)  pkcs-3(3)  1} 

DHParameter  ::=  SEQUENCE  { 
prime  INTEGER,  —  p 
base  INTEGER      —  g 


7.8      El  Gamal 

EIGamal  is  a  public  key  (asymmetric)  digital  signature  algorithm.  It  is  defined  in  [k].  Its  object  identifier  is: 

ElGamal  ALGORITHM 

PARAMETER  NULL 

::=  {encryptionAlgorithm  1} 

Editor's  Note  -  This  OID  was  assigned  by  the  Directory  SIG. 

In  [X.509],  the  ASN.1  data  element  subjectPublicKey  defined  as  BIT  STRING  should  be  interpreted  in  the 
case  of  EIGamal  as  being  of  type: 

SEQUENCE  { 

prime  INTEGER,  —  p 

base  INTEGER,    —  alpha 

key  INTEGER  —  public  key,  Y 

Also,  in  [X.509],  the  value  associated  with  the  ENCRYPTED  MACRO  should  be  interpreted  in  the  case  of 
ElGamal  as  being  of  type:  ■  ^  d; 

SEQUENCE  { 
s  INTEGER, 
r  INTEGER 
} 

The  ElGamal  technology  is  patented  in  the  United  States  [f]. 

Editor's  Note  -  Should  we  describe  and  define  OlDs  for  the  message  digest  with  EIGamal  signature 
algorithms?  There  is  a  Directory  SIG  OID  for  md2WithElGamal. 
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7.9      Data  Encryption  Standard 

The  Data  Encryption  Standard  (DES)  is  a  secret  key  (symmetric)  cryptographic  algorithm.  It  is  defined  in 
FIPS  46-1  [1].  It  is  also  defined  as  DEA-1  in  ANSI  X3.92-1981  [m]. 

Implementors  will  also  find  several  other  references  useful.  FIPS  PUB  74  [p]  provides  guidance  on  the 
implementation  and  use  of  DES  and  includes  a  complete  specification  of  the  algorithm.  SPEC  PUB  500-20 
[p]  describes  the  design  and  operation  of  the  NIST  (formerly  NBS)  testbed  that  is  used  for  the  validation 
of  DES  implementations.  It  specifies  a  set  of  291  test  cases  that  have  been  designed  to  exercise  every  basic 
element  of  the  algorithm,  and  as  a  further  check  on  the  correctness  of  an  implementation,  it  specifies  an 
extensive  Monte  Carlo  analysis.  SPEC  PUB  500-61  describes  the  design  of  four  maintenance  tests  for  DES 
implementations.  The  tests  consist  of  an  iterative  test  procedure  that  uses  a  small  program  and  minimum 
data.  The  tests  are  designed  to  be  independent  of  implementation  and  to  be  fast  enough  to  test  devices 
during  actual  operation.  The  tests  are  defined  as  four  specific  stopping  points  in  a  general  testing  process 
and  satisfy  four  testing  requirements  of  increasing  degree  of  completeness  on  the  thoroughness  of  testing 
desired.  , 

There  are  four  modes  of  operation  of  the  DES,  as  specified  by  FIPS  81  [n]  and  ANSI  X3.106-1983  [o].  The 
modes  specify  how  the  data  will  be  encrypted  and  decrypted. 


7.9.1  DES-ECB 

This  is  the  Electronic  Codebook  mode  of  operation.  Its  object  identifier  is: 

desECB  ALGORITHM 
PARAMETER  CBCParameter 
: :=  {algorithm  6} 


7.9.2  DES-CBC 

This  is  the  Cipher  Block  Chaining  mode  of  operation.  Its  object  idenfier  is: 

desCBC  ALGORITHM 
PARAMETER  CBCParameter 
t :=  {algorithm  7) 

The  PARAMETER  is  needed  to  specify  the  Initialization  Vector,  which  need  not  be  kept  secret. 


7.9.3  DES-OFB 

This  Is  the  Output  Feedback  mode  of  operation.  Its  object  identifier  and  parameters  are: 
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desOFB  ALGORITHM 
PARAMETER  FBParameter 
: : =  {algorithm  8} 

The  parameters  are  needed  to  specify  an  IV  and  the  number  of  feedback  bits. 


7.9.4  DES-CFB 

This  is  the  Cipher  Feedbacl<  mode  of  operation.  Its  object  identifier  and  parameters  are 

desCFB  ALGORITHM 
PARAMETER  FBParameter 
: :=  {algorithm  9} 

The  parameters  are  needed  to  specify  an  IV  and  the  number  of  feedback  bits. 


7.10  DES-MAC 

DES-MAC  is  a  Message  Authentication  Code  algorithm  (cryptographic  checksum)  based  on  the  DES. 

It  is  specified  in  FIPS  1 13  [s]  and  is  equivalent  to  the  binary  mode  defined  in  ANSI  X9.9-1986  [t].  Its  object 
identifier  and  parameter  are: 

desMAC  ALGORITHM 
PARAMETER  MACParameter 
::=  {algorithm  10} 

The  parameter  is  needed  to  specify  the  MAC  length  in  bits. 

DES-MAC  is  equivalent  to  DES-CBC  using  an  all  zero  Initialization  Vector  (IV),  with  all  but  the  last  cipher 
output  block  discarded.  Separate  keys  (where  one  may  simply  be  a  variant  of  the  other)  should  be  used 
if  both  DES-CBC  encrypting  and  MACing  the  same  data. 

Editor's  Note  -  We  need  to  include  the  reference  which  specifies  the  vulnerability  when  the  same  key  is  used 
to  DES-CBC  encrypt  and  MAC  the  same  data,  and  recommends  the  use  of  separate  keys. 


7.11  ASN.1 


7.11.1      Distinguished  Encoding  Rules 

In  order  to  allow  verification  of  digital  signatures  produced  by  the  SIGNED  and  SIGNATURE  MACROs  of 
[IS09594-8],  it  is  necessary  to  define  a  set  of  distinguished  encoding  rules  to  produce  an  unambiguous 
encoding  of  a  given  abstract  syntax  value.  [IS09594-8]  defines  a  number  of  such  encoding  rules  (8.7),  but 
is,  unfortunately,  underspecified  in  the  following  areas: 
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a)  Ordering  of  SET  OF  components; 

b)  Handling  of  unused  trailing  zero  bits; 

c)  Invocation  and  designation  of  new  character  sets  in  some  of  the  character  string  types. 
The  following  rules  remove  these  ambiguities: 

a)  The  [IS09594-8]  distinguished  encoding  rules  are  always  used; 

b)  For  SET  OF  types,  components  are  sorted  into  ascending  order  of  the  distinguished  encodings 
of  the  components; 

c)  For  BIT  STRINGS  with  unused  trailing  bits,  if  the  type  definition  that  specifies  the  bits  have 
significance,  then  they  are  included  in  the  encoding;  othen/vise  they  are  not; 

d)  For  those  character  strings  which  allow  it,  escape  sequences  are  generated  to  invoke  and 
designate  new  register  entries  only  when  the  register  entry  for  the  character  currently  being 
encoded  is  different  from  that  currently  designated  for  GO,  CO,  or  Cl .  All  designations  shall  be  into 
GO  or  CO.  (It  is  assumed  that  all  characters  have  entries  in  the  ISO  Registry  of  Coded  Character 
Sets.) 

NOTE  -  Rules  b,c,  and  d  are  taken  from  [ISO/CD8825-3]  (Nov.  1990),  the  ASN.1  Distinguished  Encoding 
Rules.  Other  features  of  [ISO/CD8825-3],  which  conflict  with  [1809594-8]  (e.g.,  length  encoding  for 
constructors),  are  NOT  used  by  this  lA. 

It  is  recommended  that  whenever  the  SIGNED  or  SIGNATURE  macro  is  to  be  applied  to  an  object,  the 
object  should  be  transferred  in  its  distinguished  encoded  form.  In  this  way,  when  the  resources  required 
to  encode  or  decode  an  object  exceed  the  resources  required  to  apply  the  SIGNED  or  SIGNATURE  macro, 
a  receiving  entity  may  apply  the  macro  immediately,  thus  realizing  enhanced  performance.  However,  if  the 
macro  application  is  unsuccessful,  the  object  must  be  distinguished  encoded  and  the  macro  re-applied  to 
determine  its  actual  success  or  failure. 


8     Lower  Layers  Security 
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9     Upper  Layers  Security 

This  clause  addresses  the  provision  of  security  services  in  the  Upper  layers.  The  Upper  Layers  Security 
Model  specifies  the  interactions  among  the  Upper  Layers  in  providing  and  using  security  services 
[ISO/CD10745]. 


9.1      Security  Mechanisms 


9.1.1       Peer  Entity  Authentication 


ACSE  authentication  extensions  [ISO8649][ISO8650||]  support  tv^^o-way  authentication  through  the  definition 
of  a  new  functional  unit.  When  this  functional  unit  is  employed,  additional  parameters  are  provided  by  the 
A-ASSOCIATE  service  to  indicate  this  requirement  and  convey  authentication  information  between  entities. 
The  ASN.1  definition  for  this  information  is  given  below: 


from  [ISO8650||]: 

Authentication  ::=  SEQUENCE  { 

mechanism-name  [0]  IMPLICIT  OBJECT  IDENTIFIER  OPTIONAL, 
authentication-value      [1]  CHOICE  { 

charstring  [0]  IMPLICIT  GraphicString, 

bitstring  [1]   IMPLICIT  BITSTRING, 

external  [2]  IMPLICIT  EXTERNAL, 

other  [3]  ANY  DEFINED  BY  m-^-^  Defined  by  Hechan ism-name  )  } 


Figure  1  -  A-ASSOCIATE  Authentication  Information 

These  agreements  define  the  following  mechanisms  for  use  with  this  ACSE  functional  unit: 

simple-strong  authentication  mechanism. 
9.1.1.1         Simple-Strong  Authentication 

9.1.1.1.1  Operation 


The  operation  of  the  simple-strong  authentication  mechanisms  are  based  upon  [IS09594-3]  and  [IS09594-8] 
standards.  The  sending  system  is  the  entity  requesting  authentication  of  its  identity,  and  the  receiving 
system  is  the  entity  performing  the  authentication.  The  sending  system  supplies  data  for  the  ACSE 
authentication  field  of  the  A-ASSOCI  ATE  primitive.  The  receiving  ACSE  obtains  the  ACSE  authentication  data 
from  the  A-ASSOCIATE  PDU,  and  it  performs  the  authentication  check.  If  the  check  is  successful,  the 
association  formation  succeeds  or  fails  depending  upon  other  circumstances  and  parameters.  The  use  of 
the  ACSE  authentication  fields  support  both  the  simple  and  strong  credentials  variants  of  the  [IS09594-8] 
authentication  exchanges. 
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Certificates  for  use  with  strong  authentication  must  be  compatible  with  [IS09594-8]. 
Certificates  procured  for  use  with  Internet  Privacy  Enhanced  Mail  [u]  [v]  [w]  [x]  are  completely  compatible  with 
[IS09594-8]  and  may  (subject  to  licensing  restrictions)  be  used  by  the  strong  authentication  mechanism. 
However,  Privacy  Enhanced  Mail  uses  only  a  subset  of  the  suggested  [IS09594-7]  name  forms,  and  might 
not  support  certain  name  forms  of  interest  to  specific  OIW  applications.  Examples  include  Application  Entity 
names  and  certain  name  forms  defined  by  the  North  American  Directory  Forum  in  NADF-123  [y]. 

9.1.1.1.2  Data  Structure 

Mechanism  Name 

The  following  is  the  ASN.1  description  of  the  authentication  data  structure  for  simple  or  strong 
authentication: 

simple-strong-auth-mechanism  OBJECT  IDENTIFIER  ::=  {iso  (1) 
identif ied-organization  (3) 
oiw  (14) 
secsig  (3) 

authentication-mechanisms  (3) 
simple-strong-identity-authentication  (1) 


Authentication  Value 

The  authentication  value  is  conveyed  in  the  other  option  of  the  authentication-value  field  of  ACSE 
authentication. 

Authentication-Value  ::= 

SEQUENCE  OF  DirectoryAbstractService. Credentials 

This  data  type  is  defined  in  ASN.1  module  DirectoryAbstractService  of  [IS09594-3]  as  modified  through 
resolution  of  Directory  Defect  Report  Numbers  9594/052  and  063.  The  semantics  of  all  fields  are  as 
specified  in  clause  8.1.2.1  of  [IS09594-3]. 

The  Authentication-Value  is  defined  as  a  SEQUENCE  because  it  is  permitted  to  pass  credentials  for  multiple 
entities  in  the  authentication  value.  It  is  the  responsibility  of  the  application  to  determine  the  specific 
meaning  and  use  of  multiple  credentials  in  such  a  case.  It  is  anticipated  that  specific  applications  (e.g.. 
Network  Management)  would  provide  specifications  for  handling  multiple  credentials  within  their  own  clauses 
of  this  Part. 

This  authentication  mechanism  may  employ  any  registered  authentication  algorithm;  however,  it  is 
recommended  that  the  algorithms  identified  in  clause  7  be  used. 


9.1.1.1.3  Options 

For  the  Simple  Credentials  option  of  Credentials,  the  following  agreements  apply.  Conforming 
implementations  are  not  required  to  employ  the  OPTIONAL  validity  sequence  of  the  SimpleCredential  data 
element.  Receiving  implementations  that  do  not  employ  the  validity  sequence  must  reject  an  authentication 
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value  which  does  contain  this  sequence.  Conforming  implementations  shall  employ  the  optional  password 
field  of  the  SimpleCredential  data  element. 

Note  that  the  password  may  be  hashed  using  one  way  functions  and  the  other  validity  fields.  Password  is 
either  cleartext,  Protected  1  or  Protected2  according  to  [IS09594-8]. 


9.1.1.2        External  Authentication  Mechanisms 

Externally  defined  authentication  exchanges  may  employ  the  external  [2]  option  of  the  authentication-value 
field  of  ACSE  authentication.  In  this  case  it  is  recommended  that  the  mechanism-name  be  omitted,  with  the 
particular  mechanism  in  use  being  implied  by  the  abstract  syntax  identified  in  the  external  construct. 


9.1.1.2.1  Kerberos  Version  5 


One  instance  of  an  external  authentication  mechanism  is  the  Kerberos  mechanism  defined  in  [2].  The 
Kerberos  specification  assigned  the  following  object  identifier  to  an  abstract  syntax  suitable  for  use  in  this 
way: 

[TBD] 

10   Message  Handling  System  (MHS)  Security 

All  current  MHS  security  relevant  text  appears  in  Part  8,  clause  10. 


1 1    Directory  Services  Security 


12   Network  Management  Security 

This  clause  outlines  an  approach  to  providing  security  services  for  OSI  Network  Management.  The  goals 
of  this  approach  are  to  provide  security  in  a  manner  that  is  simple  and  straight-forward  to  implement,  and 
to  avoid  any  unnecessary  computational  and  managerial  overhead.  The  approach  also  takes  into 
consideration  the  need  for  different  levels  of  security  services  within  different  network  management  domains, 
and  the  near  term  requirement  for  interoperability  of  network  management  entities  over  heterogeneous 
network  types. 
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12.1  Threats 

For  the  purpose  of  discussion,  threats  are  divided  into  two  categories:  primary  and  secondary  threats. 
Primary  threats  are  those  considered  to  be  applicable  to  the  full  range  of  network  management 
implementations,  while  secondary  threats  are  considered  to  be  applicable  to  the  more  limited  range  of  highly 
secure  implementations. 

The  primary  threats  to  be  protected  against  are  the  following: 

a)  The  masquerading  of  a  manager  or  agent  entity; 

b)  The  fabrication  or  modification  of  Common  Management  Information  Protocol  (CMIP)  data  units. 

By  countering  primary  threats,  disruption  of  network  management  services  by  the  casual  user  can  be 
avoided. 

The  secondary  threats  to  be  protected  against  are  the  following: 

a)  All  primary  threats; 

b)  The  disclosure  of  CMIP  data  units; 

c)  The  replay,  reflection,  reordering,  insertion,  or  deletion  of  CMIP  data  units. 


12.2    Security  Services 


12.2.1      Basic  Security  Services 

The  security  services  required  to  counter  primary  threats  are: 

a)  Peer  entity  authentication; 

b)  Data  origin  authentication; 

c)  Connectionless  integrity. 

Peer  entity  authentication  is  to  occur  during  the  establishment  of  an  application  association.  If  the 
association  is  successfully  established,  the  underlying  security  mechanism  provides  information  that  is 
subsequently  used  in  data  origin  authentication.  There  the  information  may  be  included  in  or,  in  some  other 
way,  transform  the  data  units  of  subsequent  exchanges  so  that  they  can  be  identified  as  originating  from 
an  authenticated  entity.  Both  authentication  security  services  are  to  be  provided  at  the  application  level  of 
the  protocol. 

Connectionless  integrity  insures  that  data  units  originating  from  an  authenticated  source  are  not  modifiable 
without  detection.  When  combined  with  a  strong  data  origin  authentication  mechanism,  the  ability  to 
fabricate  new  data  units  is  also  countered.    Connectionless  integrity  may  be  provided  at  either  the 
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application  level  of  the  protocol  or  within  one  of  the  lower  levels  of  the  protocol  (i.e.,  transport  or  network). 


12.2.2      Enhanced  Security  Services 

The  security  services  required  to  counter  secondary  threats  are: 

a)  All  basic  security  services  with  the  possible  exception  of  connectionless  integrity; 

b)  Connectionless  confidentiality; 

c)  Connection  integrity  with  or  without  recovery. 

Both  connectionless  confidentiality  and  connection  integrity  may  be  provided  at  either  the  application  level 
of  protocol  or  within  one  of  the  lower  levels  of  protocol.  The  latter  provision  is  assumed  here.  Enhanced 
security  services  are  not  discussed  further  in  this  note,  but  to  be  issued  as  a  requirement  for  the  lower  layer 
protocol  and  service  standards,  and  according  to  functional  standards  to  be  developed. 

12.3    Security  Mechanisms 

12.3.1  Peer  Entity  Authentication 

Peer  Entity  Authentication  will  use  the  ACSE  authentication  mechanism  and  associated  data  types  as  defined 
in  clause  9  of  this  Part  of  the  lAs.  The  specific  authentication  mechanism  to  be  supported  is  the  Simple- 
Strong  Authentication  defined  in  9.1.1.1. 

Support  of  ACSE  authentication  is  optional. 

12.3.2  Connectionless  Integrity 

Editor's  Note  -  Proposed  text  for  this  clause  appears  in  WIA  Part  12,  clause  12.3.2. 


16 


PART  12  -  SECURITY 


December  1991  (Stable) 


Annex  A  (normative) 
ISPICS  Requirements  List 
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Annex  D  (informative) 
EIGamal 

The  information  in  this  subclause  includes  a  tutorial  description  of  the  EIGamal  scheme  for  digital  signature 
using  the  notation  defined  in  the  Directory  Documents,  [IS09594-8].  It  is  intended  that  much  of  the  tutorial 
Information  provided  in  this  subclause  will  be  moved  to  the  security  agreements  sometime  in  the  future. 


D.1  Background 

The  EIGamal  digital  signature  scheme  is  based  on  earlier  work  done  by  Diffie  and  Hellman  [b]  in  which  it 
was  suggested  that  a  likely  candidate  for  a  one-way  function  is  the  discrete  exponential  function 


where  x  is  an  integer  between  1  and  p-1  inclusive,  where  p  is  a  very  large  prime  number,  and  where  a  is 

an  integer  such  that  ^<a>p  and  {«  mod  p,     mod  p  oT^  mod  p}  is  equal  to  the  set  {1,  2,     p-1}.  In 

algebraic  terminology,  such  an  a  is  called  a  primitive  element.  References  on  the  topic  of  primitive  roots  and 
elements  are  [aa]  and  [ab]. 

Now,  in  the  real  number  system,  if  y  =  a",  then  by  definition  of  the  logarithm  we  can  solve  for  x  using  x  = 
\oga(y).  The  same  idea  extends  to  solving  eq  (1)  for  x  so  that  inverting  f(^)  requires  calculating  discrete 
logarithms.  The  reason  Diffie  and  Hellman  suspected  eq  (1)  is  one-way  is  that  for  suitable  p,  it  is 
computationally  difficult  to  invert  According  to  the  current  state  of  the  art,  computing  discrete  logs  for 
suitable  p  has  been  found  to  require  a  number  of  operations  roughly  equivalent  to 


where  b  is  the  number  of  bits  in  p,  and  c  is  estimated  at  c  =  .69  according  to  [ac].  This  can  be  compared 
to  only  about  2  logg  p  multiplications  for  discrete  exponentiation.  If  in  fact  the  best  known  algorithm  for 
computing  discrete  logs  is  near  optimal  then  Expression  (2)is  a  good  measure  of  the  problem's  complexity 
(for  a  properly  chosen  p)  and  the  discrete  exponential  function  has  all  the  qualities  of  a  one-way  function 
as  described  by  Diffie  and  Hellman. 


D.2      Digital  Signature 

Private  Key:  denotes  the  private  key  for  user  X.  X,  is  a  randomly  chosen  integer  which  user  X  keeps 
secret. 

Public  Key:  Xp  denotes  the  public  key  for  user  X  and  is  calculated  using  the  corresponding  private  key  such 
that 


/(x)»a*(modp) 


(1) 


exp(v/QMnd) 


(2) 


Xp'a\mo6p) 


(3) 


where 
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a)  p  is  a  prime  satisfying  the  requirements  listed  in  12.2.2.4. 

b)  ct  is  a  primitive  element  mod  p. 

c)  Note  that  p  and  o  could  be  used  globally,  but  because  they  should  be  easily  changeable  (see 
12.2.2.4  for  information  about  why  these  two  parameters  should  be  easily  changeable)  it  would 
probably  be  preferable  for  each  user  to  choose  his/her  own  p  and  a.  If  users  choose  their  own, 
then  p  and  a  must  be  made  available  to  the  recipient  for  use  in  the  signature  verification  process. 

Signing  Procedure:  Suppose  user^  wants  to  sign  a  message  intended  for  recipient  S.  The  basic  idea  is  to 
compute  a  two  part  signature  (r,  s)  for  the  message  m  such  that 

a'<'^-(Ap)V*(modp)  (4) 

where  /?  is  a  one-way  hash  function. 
Compute  the  signature  (r,  s)  as  follows. 

a)  Choose  a  random  number  k,  uniformly  between  0  and  p-1  such  that  k  and  p-1  have  no  common 
divisor  except  1  (i.e.,  gcd(/c,p-1)  =  1). 

b)  Compute  r  such  that 

(5) 

c)  Use  r  to  solve  for  the  corresponding  s  as  follows. 

1)  rewrite  eq  (4)  using  eq  (5)  and  the  definition  of  the  public  key  to  get 

aM'n).„W^a'«(n^o(jp) 

Combining  exponents,  get 
eq  (7)  implies  that 

h{m)'{A^r^ksimo6p-1)  (8) 

Note  that  eq  (8)  has  a  single  solution  for  s  because  l<  was  chosen  such  that  gcd(/(,p-1)  =  1. 
^         '  See  [ad]  for  supporting  theorem. 

2)  now  solve  for  s  and  get 

s=/(/)(m)-(.4^/)(modp-1)  (9) 
'  where  /  is  computed  such  that  k  *  I  =  1  (mod  p-1). 

The  EIGamal  signature  is  comparable  in  size  to  the  corresponding  RSA  signature. 
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D.3  Verification 

The  recipient  receives  Ap,  m,  r,  s,  a,  and  p  and  computes  both  sides  of  eq  (4)  and  then  compares  the 
results. 


D.4     Known  Constraints  on  Parameters 

The  following  list  of  constraints  is  the  result  of  a  search  of  current  literature  and  may  not  be  complete: 

a)  p  must  be  prime; 

b)  p  must  be  large. 

Note  that  Expression  (2)  can  be  used  to  speculate  on  the  level  of  security  afforded  by  cr^'pto 
systems  based  on  the  discrete  log  problem.  Breaking  the  EIGamal  scheme  has  not  been  proven  to 
be  equivalent  to  finding  discrete  logs,  but  if  we  assume  equivalence  then  we  can  estimate  how  large 
p  should  be  for  a  desired  level  of  security. 

For  instance.suppose  we  wanted  to  use  Expression  (2)  to  decide  how  large  p  should  be  so  that  we 
can  be  reasonably  sure  the  system  cannot  be  broken  (using  the  best  known  algorithm)  in  a  practical 
amount  of  time.  To  be  on  the  conservative  side,  we  decide  we  want  to  protect  against  a  special 
purpose  machine  that  can  perform  10'^  operations  per  second.  Specifically,  we  want  to  know  how 
large  p  should  be  so  that  such  a  machine  would  take  at  least  one  year  to  break  the  system. 

In  one  year,  the  hypothetical  machine  can  perform  3  x  10^^  operations.  To  find  the  size  of  the 
desired  p,  solve  the  following  equation  for  b. 

exp(vCTi^)  =3x10^2  0°) 

We  get  ^"SOS  jg  number  of  bits  in  the  desired  p.  So,  the  magnitude  of  the  desired  p  is 
about  2^  which  is  roughly  266  x  10'^. 

Hence,  to  be  reasonably  sure  of  attaining  the  desired  level  of  security,  we  find  a  prime  number 
greater  than  266  x  10^^  which  satisfies  all  the  other  criteria  listed  in  this  subclause.  Our  confidence, 
however,  is  strictly  based  on  the  assumption  that  breaking  EIGamal  is  as  difficult  as  finding  discrete 
logs  and  the  assumption  that  the  best  known  algorithm  for  finding  discrete  logs  is  near  optimal. 

c)  p  should  occasionally  be  changed.  This  requirement  is  discussed  in  [ae]  and  is  related  to  the 
discovery  of  new  algorithms  for  computing  discrete  logarithms  in  GF(p). 

d)  p-1  must  have  at  least  one  large  prime  factor.  This  requirement  is  discussed  in  [ae]  and  is 
imposed  by  the  Silverman-Pohlig-Hellman  algorithm  p  which  computes  discrete  logarithms  in  GF(p) 

using  on  the  order  operations  and  a  comparable  amount  of  storage,  where  r  is  the  largest  prime 
factor  in  p-1 . 

e)  p  should  not  be  the  square  of  any  prime.  A  subexponential-time  algorithm  for  computing  discrete 
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Annex  E  (informative) 

ANNEX  FOR  SECURITY  ALGORITHMS 
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OIWSECSIGAlgorithmObjectldentif iers     {iso(l)  identif ied-organization( 3 ) 

oiw(14)  secsig(3) 

oIWSECSIGAlgorithmObjectldentif iers (1) } 

DEFINITIONS  = 
BEGIN 

EXPORTS 

—  to  be  determined 

IMPORTS 

—  none 

—  category  of  information  object 

—  defining  our  own  here;  perhaps  the  definition  should  be  imported  from 

—  { joint-iso-ccitt  ds(5)  modules(l)  usefulDef initions ( 0 ) } 

algorithm  OBJECT  IDENTIFIER  ::=  {iso(l)  identif ied-organization( 3) 

oiw(14)  secsig(3)  algorithm( 2 ) } 

—  macros 

—  taken  from  {joint-iso-ccitt  ds(5)  modules(l)  authenticationFramework ( 7 ) } 
ALGORITHM  MACRO  ::= 

BEGIN 

TYPE  NOTATION  ::=  "PARAMETER"  type 

VALUE  NOTATION  ::=  value (VALUE  OBJECT  IDENTIFIER) 

END  —  of  ALGORITHM 

—  algorithms 

md4WithRSA  ALGORITHM 
PARAMETER  NULL 
: : =  {algorithm  2} 

mdSWithRSA  ALGORITHM 
PARAMETER  NULL 
: :=  {algorithm  3} 

md4WithRSAEncryption  ALGORITHM 
PARAMETER  NULL 
: : =  {algorithm  4} 

desECB  ALGORITHM 

PARAMETER  NULL 
: : =  {algorithm  6) 

desCBC  ALGORITHM 

PARAMETER  CBCParameter 
: :=  {algorithm  7} 

CBCParameter  ::=  IV 

desOFB  ALGORITHM 

PARAMETER  FBParameter 
: :=  {algorithm  8} 

desCFB  ALGORITHM 

PARAMETER  FBParameter 
: :=  {algorithm  9} 
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FBParameter  ::=  SEQUENCE  { 
iv  IV, 

niunberOfBits  NumberOfBits 

) 

NumberOfBits  ::=  INTEGER       —  Number  of  feedback  bits  (1  to  64  bits) 

Editor's  Note  -  Check  FIPS  PUB  81  for  allowed  ranges  of  feedback 
bits  and  specify  ranges  here  as  a  comment. 

IV  ::=  CX:tet  string    --  8  octets 

desMAC  ALGORITHM 

PARAMETER  MACParameter 
: :=  {algorithm  10} 

MACParameter  ::=  INTEGER       —  Length  of  MAC  (16,  24,  32,  40,  40  or  64  bits) 

Editor's  Note  -  Check  FIPS  PUB  113  for  allowed 
END  —  of  Algorithm  Object  Identifier  Definitions 
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0  introduction 

The  OSI  Implementors'  Workshop  Virtual  Terminal  (VT)  SIG  is  making  implementation  agreements  for  the 
OSI  Basic  Class  VT  Service  and  Protocol,  ISO  9040  and  ISO  9041. 

These  implementation  agreements  fall  into  the  following  categories: 

Functionality  to  be  implemented,  i.e.,  functional  units,  etc. 

Identification  and  specification  of  VT  profiles  to  be  supported  by  conforming  implementations. 
Agreements  with  regard  to  implementation  issues  not  specified  in  ISO  9040  and  ISO  9041 . 
Resolution  of  problems  with  ISO  9040  and  ISO  9041  identified  during  implementation. 
Statement  of  requirements  to  meet  conformance  to  these  agreements. 

1  Scope 

1 .1  Phase  la  Agreements 

The  Telnet  profile  is  intended  to  support  the  following  usage: 

a)  a  simple  line  at  a  time  or  character  at  a  time  dialogue; 

b)  an  application  level  gateway  supporting  Internet  Telnet  and  ISO  VTP  interoperation. 

The  Transparent  profile  supports  the  exchange  of  uninterpreted  sequences  of  characters.  This  includes 
support  of  VT-users  who  wish  to  control  terminals  directly  through  the  use  of  embedded  control  characters 
and  escape  sequences. 

1 .2  Phase  lb  Agreements 

The  Forms  profile  is  intended  to  support  forms-based  applications  with  local  entry  and  validation  of  data  by 
the  terminal  system.  This  profile  is  now  aligned  with  the  EWOS  VT  EG  Functional  Standard. 
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1 .3  Phase  II  Agreements 

The  X.3  profile  supports  functionality  similar  to  the  CCITT  recommendations  and  could  be  used  to  implement 
an  X.3  to  ISO-VT  gateway. 

See  Working  Agreements  regarding  other  Phase  II  profiles. 

1 .4  Status 

1.4.1  status  of  phase  la 

Phase  la  of  the  VT  Agreements  was  stabilized  May  5,  1988.  This  phase  covers  the  Telnet  and  Transparent 
profiles.  No  future  enhancements  will  be  made  to  this  pliase. 

1 .4.2  Status  of  phase  lb 

Phase  lb  of  the  VT  Agreements  was  first  stabilized  December  16, 1988.  This  phase  covers  the  Forms  profile. 
Alignment  with  EWOS  required  substantial  modifications  which  were  ratified  September  15,  1989. 

1 .4.3  Status  of  phase  II 

Phase  II  is  still  in  progress  and  includes  the  remaining  profile  work  for  the  Scroll  and  S  mode  Paged  profiles. 
TN&  S^jmode  Paged  Profile  is  b^ng  progressed  a&  f*tMP  11  tdT^  (AVT^:^  S-tnoda  Paged  Pr<M&}. 
The  X.3  profile  of  phase  II  was  stabilized  December  15,  1989. 
The  Generalized  Telnet  profile  of  phase  II  was  stabilized  December  13,  1991. 

2     Normative  References 

ISO  9040:1990,  Information  technology  -  Open  Systems  Interconnection  -  Virtual  Terminal  Basic  Class 
Sen/ice. 

ISO  9041-1:1990,  Information  technology  -  Open  Systems  Interconnection  -  Virtual  Terminal  Basic  Class 
Protocol  -  Part  1:  Specification. 

ISO  9834-4,  Information  technology  -  Open  Systems  Interconnection 

-  Procedures  for  the  Operation  of  OSI  Registration  Authorities 

-  Part  4:  Register  of  VTE  Profiles. 

ISO  9834-4,  Information  technology  -  Open  Systems  Interconnection 

-  Procedures  for  the  Operation  of  OSI  Registration  Authorities 

-  Part  5:  Register  of  VT  Control  Object  Definitions. 
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3  Status 

This  version  of  the  agreements  was  completed  in  December  1991. 


4  Errata 

Editor's  Note  -  "Defect  Report"  material  may  be  included  here,  including  versions  of  implementor  agreements 
to  which  it  applies. 


Table  1  -  Technical  Errata 


06/90 

-1 

Forms  Profile.    The  "FEICO  Update  Syntax"  /^N.l  comment  which 
follows  the  definition  of  the  PriValue  type  was  corrected  to 
support  multi-octet  repertoires. 

06/90 

-2 

Forms  Profile.    The  descriptive  text  for  the  Field  Entry 
Instruction  Violation  FEE  was  corrected  to  indicate  that  both 
an  entry-control  index  and  a  FEPR  index  are  required  to 
identify  the  FEPR  concerned. 

06/90 

-3 

Forms  Profile.    The  descriptive  text  and  update  syntax  for  the 
Violation  FEC  were  corrected  to  indicate  that  both  a  FEICO- 
name  and  an  index  are  required  to  identify  a  FEIR. 

06/90 

-4 

Forms  Profile.     The  update  syntax  for  the  writeString  FER  was 

for  rppt"        iT>  alirtn  wi  ■hh   ■hhp  fl^^rr  i  ni"  i  vp   tpvi"    for   thi^  PFIR 

06/90- 

-5 

Forms  Profile.    The  descriptive  text  for  the  repertoire 
assignment  profile  argvunent  was  corrected  to  properly  identify 
the  default  value  as  the  GL  set  ISO  2375  Reg.  No.  6  (ASCII). 

06/90 

-6 

Forms  Profile.     The  concept  of  a  "current  keystroke"  was 
inserted  into  the  definition  of  the  FEICO  to  remove  ambiguity 
in  the  use  of  the  ST  and  UT  COs.    Various  FEEs,  FECs  and  FERs 
were  redefined. 

12/91 

-1 

Telnet  Profile.  Change  x-absolute  value  from  "no"  to  "yes." 

03/92 

-1 

Generalized  Telnet  Profile.  Add  conformance  statement 
regarding  the  requirement  to  accept  negotiation  of  Suppress 
GoAhead . 

03/92 

-2 

Generalized  Telnet  Profile.  Rework  Definitive  Note  8, 
expanding  the  repertoire  negotiation  capability  to  allow 
negotiation  for  the  use  any  one  of  a  number  of  non-binary 
repertoires . 

03/92 

-3 

X.3  Profile.  Correct  processing  of  terminal  break  so  that  it 
aligns  with  the  procedures  of  ccitt  X.29. 
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Table  2  -  Alignment  Errata 


06/90-7 

Forms  Profile      A  definitive  note  was  added  to  define  how  the 
host  is  notified  of  the  current  entry  location  when  data  entry 
terminates  and  the  VTE-pareuneter  access-outside-f ields  has  the 
value  "allowed." 

06/90-8 

Forms  Profile.    Three  font-assignment  profile  arguments  were 
added  to  accomodate  INTAP  requirements. 

09/90-1 

Forms  Profile.    The  emphasis  subattribute  "h"  was  added  with 
values  "F"  (Framed)  and  "C"  (Encircled). 

09/90-2 

Telnet  Profile.    Four  editorial  comments  were  incorporated  to 
align  with  the  corresponding  EWOS  Functional  Standard. 

Table  3  -  Editorial  Errata 


06/90-9 

Forms  Profile.    Two  definitive  notes  were  added  to  clarify  the 
secondary  attributes  comparison  mechanisms  for  the  FEIs  and 
FECs  that  test  equality  of  characters. 

06/90-10 

Forms  Profile.    A  definitive  note  was  added  to  clarify  the 
effect  of  associating  multiple  Character-oriented  FEIs  of  the 
scune  type  with  the  same  field. 

06/90-11 

Forms  Profile.    An  introductory  paragraph  in  the  section  "Field 
Entry  Condition  Definitions"  was  rewritten  for  clarification. 

06/90-12 

Forms  Profile.    The  descriptive  text  for  the  Write  String  field 
entry  reaction  was  modified  to  indicate  precisely  how  and  where 
the  associated  string  is  to  be  written. 

09/90-3 

X3  Profile.    The  reference  to  COs  P3  and  P4  contained  in 
comments  relating  to  DEVICE-1  were  corrected  to  reference 
elements  3  and  4  of  the  PAD  CO. 

12/90-1 

X3  Profile.  Changes  were  made  to  correct  editorial  errors 
discovered  during  the  progression  of  the  EWOS  X3  Profile 
Functional  Standard. 

09/91-1 

Scope,  Status,  and  References  clauses  were  updated. 

iiiiiii 

Status  clause  v«s  up^atedl. 
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5  Conformance 

Conformant  VT  Implementations  are  required  to  support  the  ISO  9041  Clause  13  requirements  plus  the 
additional  conformance  requirements  identified  below. 

Table  4  shows  conformance  status  for  VT  facilities  which  are  optional  In  the  ISO  VT  standard.  The  terms 
used  In  the  figure  are  defined  as  indicated  below: 

a)  "Mandatory"  Indicates  that  the  facility  must  be  provided  by  all  implementations  which  conform 
to  these  agreements; 

b)  "Optional"  Indicates  that  the  VT  facility  Is  not  required  to  meet  minimum  conformance 
requirements  but  has  been  identified  as  providing  additional  useful  capabilities; 

c)  "Profile  Dependent"  indicates  that  the  requirement  for  the  facility,  if  any,  is  included  in  the  profile 
definitions; 

d)  "Not  Addressed"  Indicates  that  the  VT  facility  Is  outside  the  scope  of  these  agreements. 
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Table  4  -  Conformance  Status  for  VT  Facilities 


IJr  o  Ti  /I  a  -f-  r\  r  TT 

Dependent 

Addressed 

Switch  Profile^ ^ 

X 

Multiple  Interaction 
Negotiation^ ) 

X 

Negotiated  Release'' ' 

X 

Urgent  Data"^^ 

X 

Break''' 

X 

Delivery  Control"'-^ 

X 

Enhanced  Access  Rules''' 

X 

Structured  COs''' 

X 

Blocks'' ' 

X 

Fields^) 

X 

RIOs^) 

X 

S-mode 

X 

A-mode 

X 

Mode  Switching  Capability 

X 

1)  It  is  not  anticipated  that  new  profiles  will  use  quarantined  delivery 
control . 

2)  Functional  Units. 

For  each  mode  of  operation  (A-mode  and  S-mode)  which  is  implemented,  the  default  profile  for  that  mode 
as  defined  in  ISO  9040  must  be  supported.  Implementations  that  support  A-mode  must  support  the  A-mode 
default  profile  and  at  least  one  additional  Workshop  approved  A-mode  profile.  The  Transparent  profile  does 
not  count  as  an  additional  A-mode  profile.  Implementations  that  support  S-mode  must  support  the  S-mode 
default  profile  and  at  least  one  additional  Workshop  approved  S-mode  profile. 

For  each  profile  implemented,  VTE  parameter  ranges  or  values  specified  in  the  Workshop-agreed  profile  and 
associated  notes  must  be  supported. 
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6.1  Protocol  Elements 

All  protocol  elements  required  by  the  ISO  9040  VT  kernel  and  Break  functional  units  are  selected. 

All  protocol  elements  required  by  the  Switch  Profile  functional  unit  are  selected  if  this  functional  unit  is  used. 
See  Table  4. 

All  protocol  elements  required  by  the  Urgent  Data  functional  unit  are  selected  if  this  functional  unit  is  used. 
See  Table  4. 

6.2  Mapping  of  Protocol  Elements 

Mapping  of  protocol  elements  on  to  ACSE  or  Presentation  Services  is  as  defined  in  ISO  9041. 

6.3  Protocol  Data  Unit  Structure 

Protocol  data  unit  structure  is  as  defined  in  ISO  9041. 

7     OIW  Registered  Control  Objects 

The  following  Control  Objects  are  used  by  more  than  one  profile.  Some  of  the  CO  parameters  are  left  with 
undefined  values  that  must  be  assigned  by  the  profile  in  which  the  Control  Object  is  used. 

7.1      Sequenced  Application  (SA) 

This  is  a  Control  object  used  to  convey  signals  from  the  application  to  the  terminal  in  sequence  with  other 
updates. 


7.1.1        Entry  Number 

To  be  supplied  by  Registration  Authority. 
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7.1.2  Name  of  Sponsoring  Body 

OSI  Implementors'  Workshop  (OIW),  VTSIG. 

7.1.3  Date 

The  date  of  submission  of  this  proposal  is  September  15,  1989. 

7.1.4  Identifier 

oiw-vt-co-misc-sa  OBJECT  IDENTIFIER  ::=  {oiw-vt-co-misc  sa(0)} 

7.1.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Sequenced  Application  Signals" 

7.1.6  CO  Parameters 

CO-structure  1 
CO-priority  "normal" 
CO-category  "symbolic" 
CO-size  1 1 

7.1.7  CO  Values  and  Semantics 

Table  5  lists  the  allowed  symbolic  values  together  with  the  integers  used  to  reference  these  values  in  the 
ASN.1  update  syntax  of  ISO  9041: 

Table  5  -  SA/UA  CO  values  and  semantics. 


Symbolic  Value 

Integer  Value 

audible_alarm 

0 

newl ines_enabled 

1 

newlines  disabled 

2 

restore 

3 

visual_alarm 

4 

keypad_enabled 

5 

keypad_disabled 

6 

7 
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keyboard_locked 

7 

keyboard_unlocked 

8 

device_disconnect 

9 

break_signal 

10 

The  semantics  of  each  value  must  be  specified  in  the  VTE  profile  which  references  this  CO. 

7.1.8  Additional  Information 

None. 

7.1.9  Usage 

Defined  in  profile. 

7.2      Unsequenced  Application  (UA) 

This  is  a  Control  object  used  to  convey  urgent  signals  from  the  application  to  the  terminal. 

7.2.1  Entry  Number 

To  be  supplied  by  Registration  Authority. 

7.2.2  Name  of  Sponsoring  Body 

OSI  Implementors'  Workshop  (OIW).  VTSIG. 

7.2.3  Date 

The  date  of  submission  of  this  proposal  is  September  15,  1989. 
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7.2.4  Identifier 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER::  =  {oiw-vt-co-misc  ua(1)} 

7.2.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Unsequenced  Application  Signals" 

7.2.6  CO  Parameters 

CO-structure  1 
CO-priority  "urgent" 
CO-category  "symbolic" 
CO-size  1 1 

7.2.7  CO  Values  and  Semantics 

Same  as  in  SA. 

7.2.8  Additional  Information 

None. 

7.2.9  Usage 

Defined  in  profile. 

7.3      Sequenced  Terminal  (ST) 

A  keyboard  can  generate  many  signals  that  may  be  given  special  meaning  to  the  application.  This  CO  is 
general  enough  to  convey  any  keyboard  event. 

7.3.1       Entry  Number 

To  be  supplied  by  Registration  Authority. 
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OSI  Implementors  Workshop  (OIW).  VTSIG. 
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7.3.3  Date 

The  date  of  submission  of  this  proposal  is  September  15,  1989. 

7.3.4  Identifier 

oiw-vt-co-misc-st  OBJECT  IDENTIFIER  ::=  {oiw-vt-co-misc  st(2)} 

7.3.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Sequenced  Terminal  Signals" 

7.3.6  CO  Parameters 

CO-structure  1 
CO-priority  "normal" 
CO-category  "integer" 
CO-size  65535 

7.3.7  CO  Values  and  Semantics 

The  values  of  the  CO  are  composite,  with  values  from  Table  6  giving  meaning  to  the  values  in  the  hex  range 
00-FF  when  added  to  them. 

Table  6  -  ST/UT  CO  composite  values 


hex  value 

meaning 

100 

special  key  -  labeled^ ^ 

200 

function  key  depressed 

400 

control  key  depressed 

800 

shift  key  depressed 

1000 

alt  key  depressed 

1)  possible  special  key  values  are 
as  defined  by  the  STCO  ASN.l  module. 
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The  special  key  and  the  function  key  are  mutually  exclusive.  If  neither  the  function  keys  nor  the  special  keys 
are  pressed,  then  the  value  in  the  hex  range  00-FF  will  be  that  of  the  normal,  unshifted  code  combination 
generated  by  the  alpha-numeric  key.  Values  in  the  hex  range  00-FF  are  not  valid  values  for  the  data  element 
of  this  Control  Object. 

The  control,  shift,  and  alt  keys  may  appear  in  any  combination  with  the  special  or  function  keys. 

The  shift  key  must  occur  in  combination  with  at  least  one  of  the  other  keys  in  the  above  table  to  cause  the 
value  to  fall  outside  the  repertoire  of  the  display  object. 

When  the  special  key  is  depressed,  the  value  of  the  CO  content  will  be  as  given  in  the  ASN.1  module  below 
for  the  value  in  the  hex  range  of  00-FF.  Otherwise,  the  value  will  be  defined  to  be  the  IA5  value  associated 
with  the  key. 

STCO  DEFINITIONS  ::=  BEGIN 


Key  ::=  INTEGER  { 


break 

(0), 

bell 

(1). 

backspace 

(2), 

tab 

(3), 

backTab 

(4), 

lineFeed 

(5), 

carReturn 

(6), 

cancel 

(7), 

substitute 

(8), 

escape 

(9). 

plus 

(10), 

minus 

(11) 

multiply 

(12). 

divide 

(13), 

leftArrow 

(14) 

rightArrow 

(15). 

upArrow 

(16), 

downArrow 

(17) 

insert 

(18), 

delete 

(19), 

insertLine 

(20) 

deleteLlne 

(21), 

home 

(22), 

end 

(23) 

PageUp 

(24), 

PageDown 

(25). 

pa1 

(26) 

pa2 

(27). 

pa3 

(28), 

help 

(29) 

statusProcess 

(30). 

interruptProcess 

(31), 

terminateProcess 

(32) 

abortOutput 

(33). 

formFeed 

(34), 

clear 

(35) 

print 

(36). 

refresh 

(37), 

systemRequest 

(38) 

endOfRecord 

(39), 

endOfFile 

(40), 

suspendProcess 

(41) 

--  Names  for  combination  keystrokes  are  formed  by  converting  the 
--  initial  letter  to  upper  case  and  prefixing  with  'Ctrl',  'shift'  or 
--  'alt',  which  adds  1024,  2048  or  4096  respectively  to  the  value. 
--  These  prefixes  may  be  used  in  combination  with  one  another  by  a 

repetition  of  this  conversion  process,  provided  that  they  appear 
-  from  left  to  right  in  the  order  'Ctrl',  'shift',  'alt'.  ASN.1 
--  formally  does  not  allow  such  descriptive  additions  but  it  would  be 
--  very  lengthy  to  write  them  all  in  full  --  } 

END   *(STCO  DEFINITIONS)* 

VTE  profile  definitions  may  refer  to  this  module  for  convenience  in  describing  semantics. 
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7.3.8  Additional  Information 

None. 

7.3.9  Usage 

Defined  in  profile. 

7.4      Unsequenced  Terminal  (UT) 

Keyboard  events  may  need  to  be  conveyed  urgently,  out  of  sequence  with  normal  updates.  This  CO  is  used 
to  signal  such  events  from  the  terminal  to  the  application. 

7.4.1  Entry  Number 

To  be  supplied  by  the  Registration  Authority. 

7.4.2  Name  of  Sponsoring  Body 

OSI  Implementors  Workshop  (OIW),  VTSIG 

7.4.3  Date 

The  date  of  submission  of  this  proposal  is  September  1 5,  1 989. 

7.4.4  Identifier 

oiw-vt-co-misc-ut  OBJECT  IDENTIFIER  ::=  {oiw-vt-co-misc  ut(3)} 

7.4.5  Descriptor  Value 

"OIW  VT  CO  for  conveying  Unsequenced  Terminal  Signals" 


Decemberl99l  (Stable) 
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7.4.6 


CO  Parameters 


CO-structure  1 

CO-priority  "urgent" 

CO-category  "integer" 

CO-size  65535 


7.4.7 


CO  Values  and  Semantics 


Same  as  in  ST. 


7.4.8 


Additional  Information 


None. 


7.4.9  Usage 

Defined  in  profile. 

8     OIW  Defined  Profiles 

These  profiles  are  defined  using  the  conventions  specified  in  Annex  A  of  ISO  9040. 

8.1      Telnet  Profile 

OIW  VTE-Profile  Telnet-1988  (r1,  r2) 

8.1.1  Introduction 

This  profile  provides  support  for  TELNET-like  operation  for  users  of  the  ISO  Virtual  Terminal  Service.  It  is 
based  on  the  IS  version  of  ISO  9040  and  ISO  9041. 

8.1.2  Association  Requirements 
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8.1.2.1  Functional  Units 

The  Urgent  Data  Functional  Unit  is  optional,  but  should  be  used  whenever  available. 

8.1.2.2  Mode 

This  is  an  A-mode  profile. 


8.1.3       Profile  Body 

Display-objects  =  *(double  occurrence)* 
{ 

{ 

display-object-name  =  D,  *(DISPLAY)* 
do-access  =  "WACA", 

dimensions  =  "two", 

x-dimension  = 

{ 

x-bound  =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute  =  "yes",        *(See  Definitive  Note  4)* 

x-window  =  profile-argument-rl 

y-dimension  = 
{ 

y-bound        =  "unbounded", 
y-addressing  =  "higher  only", 
y-absolute      =  "no", 
y-window       =  1 

}, 

erasure-capability  =  "yes", 
repertoire-capability  =  2, 
repertoire-assignment  =  profile-argument-r2, 
repertoire-assignment  =  <ESC>  2/5  2/15  4/2 
}. 
{ 

display-object-name  =  K,  *(KEYBOARD)* 
do-access  =  "WACI", 

dimensions  =  "two", 

x-dimension  = 

{ 

x-bound        =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute      =  "yes",        *{See  Definitive  Note  4)* 
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}. 


x-window       =  profile-argument-r1 

}. 

y-dimension  = 
{ 

y-bound        =  "unbounded", 
y-addressing  =  "higher  only", 
y-absolute      =  "no", 
y-window       =  1 

}. 

erasure-capability  =  "yes", 
repertoire-capability  =  2, 
repertoire-assignment  =  profile-argument-r2, 
repertoire-assignment  =  <ESC>  2/5  2/15  4/2 
} 


Control-objects  =  *  (multiple  occurrence)* 
{ 

{  *(SYNCHRONIZE)* 

co-name  =  SY, 

co-access  =  "NSAC", 

CO-category  =  "symbolic", 

co-size  =  1, 

CO-priority  =  "urgent" 

}, 

{  *(DISPLAY-SIGNAL)* 

co-name  =  Dl, 

co-access  =  "WACA", 

CO-category  =  "boolean", 

CO-size  =  5, 

CO-priority  =  "normal", 

co-trigger  =  "selected" 

}. 

{  *(KEYBOARD-SIGNAL)* 

CO-name  =  KB, 

co-access  =  "WACI", 

CO-category  =  "boolean", 

CO-size  =  5, 

CO-priority  =  "normal", 

co-trigger  =  "selected" 

{  *(NEGOTIATION  BY  INITIATOR)* 

CO-name  =  Nl, 

co-access  =  "WACI", 

CO-category  =  "boolean", 

co-size  =  4, 
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CO-priority 
CO-trigger 

{  *(NEGOTIATION  BY 
CO-name 
CO-access 
CO-category  = 
co-size 
CO-priority 
CO-trigger 

}. 

{  *(GO-AHEAD)* 
CO-name 
CO-access 
CO-category  = 
co-size 
CO-priority 
CO-trigger 

} 


=  "normal", 
=  "selected" 

ACCEPTOR)^ 
=  NA, 
=  "WACA", 
=  "boolean", 
=  4, 

=  "normal", 
=  "selected" 


GA, 

"NSAC", 

"boolean", 

1, 

"normal", 
"selected" 


Device-objects  =  *  (double  occurrence)* 
{ 

{ 

device-name  =  DISPLAY-DEVICE, 
device-display-object  =  D, 
device-default-CO-initial-value  =  1."true",*("on")* 
device-minimum-X-array-length  =  1,*(no  constraint)* 
device-minimum-Y-array-length  =  1,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  NA, 
device-control-object  =  Dl, 
device-control-object  =  GA, 

*(SYNC,NEGOTIATE-ACCEPTOR,DISPLAY-SIGNAL, 
GO-AHEAD)* 
device-default-CO-access  =  "WACA", 
device-default-CO-priority  =  "normal" 

*(other  device  object  parameters  assume  corresponding  DO  values)* 

}. 

{ 

device-name  =  KEYBOARD-DEVICE, 
device-display-object  =  K, 
device-default-CO-access  =  "WACI", 
device-default-CO-priority  =  "normal", 
device-defau!t-CO-initial-value  =  1."true",*("on")* 
device-minimum-X-array-length  =  1,*(no  constraint)* 
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device-minimum-Y-array-length  =  1,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  Nl, 
device-control-object  =  KB, 
device-control-object  =  GA, 

*(SYNC,NEGOTIATE-INITIATOR,KEYBOARD-SIGNAL, 
GO-AHEAD)* 

*  (other  device  object  parameters  assume  corresponding  DO  values)* 
} 

}. 

Type  of  delivery  control  =  "simple-delivery-control." 


8.1.4       Profile  Arguments 

r1  -  is  used  to  represent  the  line  length  as  the  value  of  VIE  parameter  x-window  for  both  display  objects. 
This  argument  is  mandatory  and  takes  a  nonnegative  integer  value.  This  argument  is  identified  by 
the  identifier  for  x-window  for  display  object  D. 

r2  -  is  used  to  designate  the  default  repertoire  for  both  display  objects.  This  argument  is  optional,  if  not 
present  the  full  US  ASCII  set  is  the  default.  This  argument  is  identified  by  the  identifier  for  repertoire 
assignment  for  the  display  object  D. 


8.1.5       Profile  dependent  Control  Object  Information 

This  profile  does  not  reference  any  Control  Objects  which  are  not  defined  within  this  profile. 


8.1.6       Profile  Notes 


8.1 .6.1         Definitive  Notes 

1.       Booleans  in  the  KB  and  Dl  control  objects  are  used  in  this  profile  to  correspond  to  TELNET 
commands  as  follows: 
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Table  7  -  KB/DI  CO  value  definitions 


Control  Object 

Boolean 

TELNET 

DI/KB 

1 

IP 

DI/KB 

2 

AO 

DI/KB 

3 

AYT 

DI/KB 

4 

DM 

DI/KB 

5 

BREAK 

The  equivalent  of  a  TELNET  command  is  achieved  by  selecting  the  boolean  that 
corresponds  to  the  desired  TELNET  command.  Selecting  a  boolean  in  the  Dl  or 
KB  control  object  means  setting  the  value  of  the  desired  boolean  to  "true."  The 
usage  of  the  mask  element  of  the  boolean  update  is  as  specified  in  ISO  9041. 

2.  The  equivalent  of  a  TELNET  SYNCH  command  is  achieved  by  updating  the  SY  control  object  with 
the  single  symbolic  value  of  "SYNCH"  (which  is  mapped  onto  the  integer  value  1),  and  immediately 
updating  the  Dl  (or  KB)  control  object  selecting  the  DM  boolean.  IP,  AO,  AYT,  or  BREAK 
commands  may  be  accompanied  by  a  SYNCH  command  by  updating  the  SY  control  object  and 
then  updating  the  Dl  or  KB  control  object  selecting  both  the  DM  and  the  other  desired  boolean. 
When  an  update  to  the  SY  control  object  is  received  subsequent  display  object  updates  are 
discarded  until  an  update  to  the  Dl  or  KB  control  object  is  received  selecting  the  DM  bit.  If  a  VT- 
BREAK  is  received  after  an  SY  CO  update  has  been  received  and  prior  to  the  corresponding  Dl  or 
KB  CO  update  selecting  the  DM  boolean,  the  discarding  of  updates  is  terminated.  This  is  necessary 
because  the  VT-BREAK  may  have  caused  the  Dl  or  KB  CO  update  to  be  purged. 

3.  The  Nl  and  NA  control  objects  are  used  to  emulate  the  TELNET  option  negotiation  facility.  The 
facility  is  symmetric,  allowing  either  party  to  open  negotiation  for  a  change  of  mode,  and  every 
negotiation  must  be  accepted  or  rejected  by  the  opposite  party.  The  rules  for  negotiation  for  each 
of  the  option  controls  are  as  stated  in  RFC  854  and  as  given  below: 

a.  Only  open  negotiation  for  a  change  from  the  current  state; 

b.  Only  acknowledge  negotiation  for  a  change  from  the  current  state; 

c.  Do  not  send  any  object  updates  with  a  negotiation  outstanding  except  an  update  to  the 
Nl  (or  NA)  control  object  to  acknowledge  negotiation. 

For  full  symmetry,  both  the  Nl  and  NA  control  objects  have  the  same  value  definition  and  consist 
of  4  booleans  with  the  semantics  given  in  Table  8. 


I 

December  1991  (Stable)  ' 
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Table  8  -  NI/NA  CO  value  definition 


BIT 

Option 

Value 

1 

Remote  Echo 

"false"  Echo  is  Local; 
"true"  Echo  is  remote 

2 

Suppress  Go  Ahead 

"false"  GO  Ahead; 

"true"  Suppress  Go  Ahead 

3 

Binary  WACA 

"true"  use  binary  WACA; 

"false"  use  default  or  negotiated 

repertoire  for  WACA  display  object 

4 

Binary  WACI 

"true"  use  binary  WACI; 

"false"  use  default  or  negotiated 

repertoire  for  WACI  display  object 

Booleans  3  and  4  control  the  use  of  the  Transparent  character  set  for  the  D  and  K  display  objects 
respectively.  A  value  of  "true"  indicates  the  use  of  the  binary  repertoire;  "false"  indicates  the  use 
of  the  negotiated  repertoire.  When  a  party  wants  to  change  a  repertoire  assignment,  it  must 
complete  a  successful  TELNET  negotiation  to  change  the  option  control.  Then  the  party  with  the 
access  rights  to  the  display  object  in  question  is  required  to  perform  the  corresponding  secondary 
attribute  modal  update. 

4.  The  TELNET  EC  (erase  character)  command  will  be  mapped  to  a  pointer  relative  (x:=  x-1)  update 
and  an  erase  current  update.  This  is  the  only  instance  when  backward  explicit  addressing  Is 
permitted. 

The  TELNET  EL  (erase  line)  command  will  be  mapped  to  an  erase-full-x-arrav  update  (an  erase 
operation  where  the  extent  is  defined  as  <"start-x,"(Yc,Xc-1)>  and  a  pointer  update  to  set  x  =  1. 
This  is  the  only  instance  when  absolute  explicit  addressing  is  permitted. 

5.  The  X  address  of  the  pointer  can  be  moved  fonA/ard  only  by  implicit  pointer  addressing.  Addressing 
of  the  Y  dimension  is  limited  to  the  next  X-array  update  operation. 

6.  The  VT  next  X-arrav  update  operation  will  be  sent  in  place  of  the  TELNET  NVT  "CR.LF"  sequence. 

7.  While  the  "binary"  repertoire  is  being  used  no  mapping  to  pointer  addressing  or  erase  operations 
will  be  done. 

8.  The  repertoire  designation  "7-bit  ASCII  (GO+CO)"  refers  to  the  repertoire  invoked  by  ISO  2022 
defined  character  set  designating  escape  sequences  <ESC>  2/8  4/2,  "void,"  <ESC>  2/1  4/0.  The 
repertoire  designation  "7-bit  ASCII  (GO  only)"  refers  to  the  repertoire  invoked  by  the  ISO  2022 
defined  character  set  designating  escape  sequence  <ESC>  2/8  4/2.  The  designation  "binary" 
refers  to  the  "Virtual  Terminal  Service  Transparent  Set"  registered  in  the  International  Register  under 
ISO  2375  register  value  125  and  invoked  by  the  escape  sequence  <ESC>  2/5  2/15  4/2. 

9.  No  termination  event  list  is  specified  so  that  data  buffering  and  delivery  can  be  controlled  according 
to  context.  If  local  echoing  is  enabled,  the  local  newline  or  enter  event  shall  trigger  a  VT-DELIVER 
request.  With  remote  echo  a  timeout  or  buffer  length  may  be  used  to  trigger  a  VT-DELIVER  request. 
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8.1 .6.2        Informative  Notes 

1 .  Users  of  this  profile  should  refer  to  the  TELNET  specification  (MiL-STD-1 782)  and  RFCs  854  and  855 
for  semantics  of  the  TELNET  commands.  These  documents  can  be  obtained  by  contacting  SRI 
International,  DDN  Network  Information  Center,  333  Ravenswood  Ave.,  Menio  Park,  CA  94025,  (415) 
859-3695. 

2.  An  update  to  the  GA  control  object  is  equivalent  to  the  TELNET  Go  Ahead  command. 

3.  If  the  "go  ahead"  facility  has  been  negotiated  then  following  a  VT-BREAK,  only  the  association 
acceptor  has  the  right  to  send  data.  In  the  event  of  VT-BREAK  the  echo  control  objects  are 
reinitialized  to  "false,"  meaning  local  echo.  If  remote  echo  is  desired  it  must  be  re-negotiated 
following  \n"-BREAK. 

4.  Negotiation  of  TELNET  options  other  than  echo,  transmit  binary,  and  SUPPRESS  GO  AHEAD  is  not 
supported  by  this  profile.  Negotiations  for  these  three  options  can  take  place  at  any  time  during 
a  session. 


8.1.7       Specific  Conformance  Requirements 

The  following  character  sets  are  required: 

The  GO  character  set  for  U.S.  7-bit  ASCII  (values  32-126); 
The  full  U.S.  7-bit  ASCII  (values  0-127). 

The  transparent  character  set,  see  Definitive  Note  8  in  clause  8.1.6.1. 


8.2      Transparent  Profile 

OIWVTE-Profile  Transparent- 1988  (r1) 


8.2.1  Introduction 

This  profile  is  intended  to  provide  a  transparent  mode  of  operation  which  allows  VT-users  to  exchange 
transparently  uninterpreted  sequences  of  characters  but  with  the  added  benefit  of  delivery  control  to  enable 
the  VT-users  to  determine  when  the  character  sequences  are  to  be  delivered. 

This  profile  may  be  used  when  VT-users  wish  to  control  terminals  directly  through  the  use  of  embedded 
control  characters. 


20 


PART  14  -  VIRTUAL  TERMINAL  December  1991  (Stable) 

8.2.2       Association  Requirements 


8.2.2.1         Functional  Units 

No  additional  functional  units  are  required  by  this  profile. 


8.2.2.2  Mode 

This  is  an  A-mode  profile. 


8.2.3       Profile  Body 

Display-objects  *(double  occurrence)*  = 
{ 

{ 

display-object-name  =  D1, 

do-access  =  "WACA", 

dimensions  =  "one", 

x-dimension  = 

{ 

x-addressing  =  "not-permitted" 

repertoire-assignment  =  profile-argument-r1 

}. 

{ 

display-object-name  =  D2, 

do-access  =  "WACI", 

dimensions  =  "one", 

x-dimension  = 

{ 

x-addressing  =  "not-permitted" 

repertoire-assignment  =  profile-argument-rl 
} 

}. 

type-of-delivery-control  =  "simple-delivery-control." 
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8.2.4       Profile  Arguments 

r1  -  is  optional  and  enables  negotiation  of  a  value  for  the  VTE-parameter  repertoire-assignment  for  tine 
two  display  objects  (which  always  have  the  same  value  of  repertoire  assignment  when  the  profile 
is  called).  The  default  value  of  this  argument  is  the  "Virtual  Terminal  Transparent  Set"  registered  in 
the  International  Register  under  ISO  2375  register  value  125,  invoked  by  the  escape  sequence 
<ESC>  2/5  2/15  4/2.  This  argument  is  identified  by  the  identifier  for  repertoire-assignment  for 
display  object  D1. 


8.2.5       Profile  dependent  Control  Object  Information 

This  profile  does  not  reference  any  Control  Objects. 


8.2.6       Profile  Notes 

1.  This  profile  is  intended  primarily  for  applications  requiring  a  simultaneous  two  way  exchange  of 
sequences  of  uninterpreted  characters.  The  semantics  usually  associated  with  the  display  object 
are  not  used;  for  the  purposes  of  this  profile,  the  primary  attributes  of  the  character-box  graphic 
elements  are  actually  octets  which  are  passed  directly  to  the  real  device.  There  is  no  relationship 
between  the  elements  of  the  X-array  and  the  character  boxes  of  the  real  device;  the  secondary 
attributes  of  the  display  object  are  not  utilized.  The  only  operation  on  the  display  object  which  must 
be  supported  is  the  text  operation.  An  alternative  repertoire  may  be  selected. 


8.2.7       Specific  Conformance  Requirements 

Support  for  the  default  (transparent)  character  set  is  required.  It  is  strongly  recommended  that  the  profile 
argument  not  be  used. 


8.3      Forms  Profile 

OIW  VTE-Profile  Forms-1989  (r1,r2,  .  .  .  r28) 


8.3.1  Introduction 

This  S-mode  VTE-profile  is  intended  for  supporting  the  use  of  forms  based,  field  oriented  data  entry 
applications  between  a  terminal  and  a  host  system. 

It  provides  facilities  for: 

a)  defining  and  using  screen  forms; 

b)  defining  field  validation  and  field  entry  rules; 
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c)  controlling  and  validating  field  entry. 
This  VTE-profile  includes  support  of  an  optional  terminal-end  locally  attached  printer. 


8.3.2       Association  Requirements 


8.3.2.1         Functional  Units 

The  following  VT  functional  units  are  required  for  operation  with  this  profile: 

a)  Enhanced  access-rules; 

b)  Structured  COs; 

c)  Fields; 

d)  Reference  Information  Objects. 

The  following  VT  functional  units  are  optional  for  operation  with  this  profile: 
Urgent  Data 


8.3.2.2  Mode 

This  is  an  S-mode  profile. 


8.3.3       Profile  Body 

Display-objects  *  (single  occurrence)*  = 
{ 

display-object-name  =  A, 
DO-access  =  "WAVAR", 

dimensions  =  "three", 

x-dimension  = 
{ 

x-bound 
x-addressing 
x-absolute 
x-window 

}. 

y-dimension  = 
{ 

y-bound 


profile-argument-r1 , 
"no  constraint", 
"yes", 
x-bound 


=  profile-argument-r2, 
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y-addressing 
y-absolute 
y-window 

}. 

z-dimension  = 
{ 

z-bound 
z-addressing 
z-absolute 
z-window 
}, 

erasure-capability  =  "yes", 
repertoire-capability  *(implicitly  defined  by  r4)*, 
repertoire-assignment  =  profile-argument-r4, 

font-capability  *(implicitly  defined  by  r5)*, 
font-assignment  =  profile-argument-r5, 
DO-emphasis  =  profile-argument-r6, 

foreground-colour-capability  =  profile-argument-r7, 
foreground-colour-assignment  =  profile-argument-r8, 
background-colour-capability  =  profile-argument-r7, 
background-colour-assignment  =  profile-argument-rS, 

block-definition-capability  =  "no", 
field-definition-capability  =  "yes", 
max-fields  =  "unbounded", 
max-field-elements  =  profile-argument-r10, 
access-outside-fields  =  profile-argument-r1 1 
}> 


"no  constraint", 

"yes", 

y-bound 


"unbounded", 
"no  constraint", 
"no", 

profile-argument-r3 


Control-objects  = 
{ 

{  *  (Field  Definition  CO)' 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

}> 


=  FD, 

=  vt-b-sco-fdco, 

=  "non-parametric", 

=  "WAVAR"  -1-  profile-argument-r12, 

=  "normal", 

=  "not-selected" 


{  *(Field  Entry  Instructions  CO)* 
CO-name  =  El, 

CO-type-identifier  =  "mandatory-feico", 

CO-structure  =  "non-parametric". 
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CO-access 
CO-priority 
CO-trigger 

}, 

{  *  (Field  Entry  Pilot  CO)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

}. 

{  *  (Context  CO)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 


=  "WAVAR"  -I-  profile-argument-r12, 
=  "normal", 
=  "not-selected" 


EP, 

"mandatory-fepco", 

"non-parametric", 

"WAVAR"  +  profile-argument-r12, 

"normal", 

"not-selected" 


CC, 

vt-b-sco-cco, 
6. 

"WAVAR", 

"normal", 

"not-selected" 


{  *(Transmission  Policy  CO)' 
CO-name 
CO-type-identifier 
CO-structure 
CO-access 
CO-priority 
CO-trigger 
CO-category 
co-size 
}. 

{  *(Multiple  occurrence  of  optional  COs.  Ail  unspecified  VTE-parameters  of  such  COs 
are  determined  by  their  CO-type-identifier  through  their  registered  definition.  They  may 
include  parameters  specified  to  be  additional  profile  arguments,  which  should  follow  the 
appropriate  CO-type-identifier  argument  value)* 


TP, 

vt-b-sco-tpco, 
1, 

"WAVAR"  -I-  profile-argument-r12, 

"normal", 

"not-selected", 

"boolean", 

4 


CO-name 

CO-type-identifier 

}. 

{  *(Form  Waiting  Time  CO)' 
CO-name 
CO-type-identifier 
CO-structure 


=  profile-argument-r13, 
=  profile-argument-r14 


=  WT, 

=  "waiting-time", 
=  1, 
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CO-access 

CO-priority 

CO-trigger 

CO-category 

co-size 


=  "WAVAR", 
=  "normal", 
=  "not-selected", 
=  "integer", 
=  65535 


*(The  initial  value  for  WT  is  zero,  implying  that  a  Form  Waiting  Time  is  not  to  be  used.)* 

*(The  following  four  COs,  (SA,  UA,  ST,  and  UT),  are  registered  with  the  01 W  registration  authority 
and  are  referenced  by  this  profile.)* 


{  *(As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

co-size 

}. 

{  *(As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

CO-size 

}, 

{  *(As  defined  in  clause  7)* 

CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

CO-size 

}. 


SA, 

oiw-vt-co-misc-sa, 
1, 

"WAVAR"  +  profile-argument-r12, 

"normal", 

"not-selected", 

"symbolic", 

11 


UA, 

oiw-vt-co-misc-ua, 
1, 

profile-argument-rl  2, 

"urgent", 

"not-selected", 

"symbolic", 

11 


ST, 

oiw-vt-co-misc-st, 
1, 

"WAVAR"  +  opposite  of  profile-argument-rl 2, 

"normal", 

"not-selected", 

"integer", 

65535 


{  *(As  defined  in  clause  7)* 
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CO-name 

CO-type-identifier 

CO-structure 

CO-access 

CO-priority 

CO-trigger 

CO-category 

co-size 

} 


=  UT, 

=  oiw-vt-co-misc-ut, 
=  1, 

=  opposite  of  profile-argument-r12, 

=  "urgent", 

=  "not-selected", 

=  "integer", 

=  65535 


Device-objects  *  (single  or  double  occurrence)*  = 
{ 

{ 

device-name  =  D, 

device-default-CO-access  =  "WAVAR", 
device-default-CO-priority  =  "normal", 
device-default-CO-trigger  =  "not-selected", 
device-default-CO-initial-value  =  1  ."true", 
device-repertoire-assignment  =  profile-argument-r15, 
device-font-assignment  =  profile-argument-r16, 
device-emphasis  =  profile-argument-r17, 
device-foreground-colour-assignment  =  profile-argument-r1 8, 
device-background-colour-assignment  =  profile-argument-r19, 
device-minimum-X-array-length  =  profile-argument-r20, 
device-minimum-Y-array-length  =  profile-argument-r21, 
device-control-object  =  FD, 
device-control-object  =  CC, 
device-control-object  =  SA, 
device-control-object  =  UA, 
device-control-object  =  ST, 
device-control-object  =  UT, 
device-control-object  =  WT, 
device-control-object  =  TP, 
device-control-object  =  profile-argument-r22, 
device-display-object  =  A 
}, 

IF  r23  =  "true"  THEN   *(define  printer)* 
{ 

device-name  =  P, 

device-default-CO-access  =  "NSAC", 
device-default-CO-priority  =  "high", 
device-default-CO-trigger  =  "not-selected", 
device-default-CO-initial-value  =  1  ."false", 
device-repertoire-assignment  =  profile-argument-r24. 
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device-font-assignment  =  profile-argument-r25, 
device-emphasis  =  profile-argument-r26, 
device-foreground-colour-assignment  =  profile-argument-r27, 
device-background-colour-assignment  =  profile-argument-r28, 
device-minimum-X-array-length  =  profile-argument-r29, 
device-minimum-Y-array-length  =  profile-argument-r30, 
device-control-object  =  FD, 
device-control-object  =  SA, 
device-control-object  =  UA, 
device-control-object  =  profile-argument-r31, 
device-display-object  =  A 

} 


type-of-delivery-control  =  "simple  delivery  control." 


8.3.4       FIXED  Field  Entry  Instruction  Definitions  -  non-parametric 


8.3.4.1        Optional  Field 

Field  entry  is  optional.  This  FEI  Is  provided  for  completeness  only,  as  a  field  not  linked  to  one  of  the 
Mandatory  field,  Selectable  field  or  Protected  field  FEIs  is  necessarily  optional.  This  FEI  can  never  be 
violated. 


8.3.4.2        Mandatory  Field 

Field  entry  is  mandatory.  Violation  of  this  FEI  will  occur  if  all  array  elements  of  this  field  are  empty  when 
one  of  the  reactions  FER01  (T ransmit  updates)  or  FER02  (Relinquish  WAVAR)  is  initiated.  See  also  the 
specification  of  these  reactions  given  below. 


8.3.4.3        Protected  Field 

The  field  is  protected  from  field  entry.  Violation  of  this  FEI  will  occur  if  an  attempt  is  made  to  change  the 
primary  or  secondary  attribute  of  any  array  element  of  this  field. 


8.3.4.4        Fill  Field 

All  array  elements  k  =  1  through  k=last  must  have  a  primary  attribute.  Violation  of  this  FEI  will  occur  if  any 
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array  element  of  this  field  is  empty  when  one  of  the  reactions  FER01  (Transmit  updates)  or  FER02 
(Relinquish  WAVAR)  is  initiated.  See  also  the  specification  of  these  reactions  given  below. 


8.3.4.5        Echo  Received  Character 

Allowed  field  entry  characters  are  to  be  echoed  as  received.  This  FEI  is  provided  for  completeness  only, 
as  by  default  characters  will  be  echoed  as  received  unless  the  field  is  linked  to  either  the  Echo  Off  or  the 
Echo  Specified  Character  FEI.  This  FEI  can  never  be  violated. 


8.3.4.6         Echo  Off 

Received  field  entry  characters  should  not  be  echoed.  This  FEI  can  never  be  violated. 


8.3.4.7        Ignore  Case 

If  this  FEI  is  linked  to  a  field,  upper  and  lower  case  alphabetic  characters  should  be  considered  as  equivalent 
during  the  validation  of  field  input  against  all  other  FEIs  linked  to  the  same  field.  This  affects  the 
interpretation  of  the  Allowed  First  Characters,  Allowed  Characters,  Disallowed  Characters  and  Allowed  String 
Values  FEIs,  including  the  precedence  rules  between  the  first  three  of  these  FEIs.  This  FEI  can  never  be 
violated. 


8.3.4.8        Inhibit  Logical  Rendition  Attribute  Operation 

No  form  of  logical  attribute  operation,  with  the  exception  of  character  repertoire  switching  as  given  below, 
can  be  performed  on  the  field.  Character  repertoire  changes  are  permitted  if  also  permitted  by  Allowed  First 
Characters  or  Allowed  Characters,  see  below.  This  FEI  is  intended  to  be  used  when  the  rendition  secondary 
attributes  are  to  be  kept  under  "application"  control.  See,  for  example.  Allowed  First  Characters  for  a  case 
of  reference  to  the  field  modal  values. 


8.3.5       DYNAMIC  Field  Entry  Instruction  Definitions  -  parametric 


8.3.5.1         Selectable  field 

The  field  is  selectable,  i.e.,  field  entry  is  not  permitted  but  information  is  conveyed  by  the  selection  of  one 
such  field  from  a  number  of  alternatives. 

The  manner  in  which  the  field  that  is  the  current  candidate  for  selection  is  displayed  on  the  real  device  is 
determined  by  the  optional  "visit"  parameter  of  this  FEI.  This  parameter  specifies  the  secondary  attributes 
to  be  used  for  showing  or  highlighting  this  candidate  to  the  user.  If  it  is  omitted,  an  implementation- 
dependent  default  is  used. 
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The  manner  in  which  the  field  that  is  actually  selected  is  displayed  on  the  real  device  is  determined  by  the 
optional  "select"  parameter  of  this  FEI.  This  parameter  specifies  the  secondary  attributes  to  be  used  for 
showing  or  highlighting  the  selected  field  to  the  user.  If  It  is  omitted,  an  implementation-dependent  default 
is  used. 

The  mechanisms  for  moving  among  candidates  and  for  actually  selecting  the  current  candidate  are 
implementation  defined.  Typically,  a  selectable  field  will  be  considered  as  a  candidate  for  selection  when 
the  cursor  is  placed  on  a  character  within  the  selectable  field.  Actual  selection  generates  the  Field  Selected 
FEE.  A  selected  field  is  indicated  in  a  delivered  update  by  an  addressing  operation  setting  k=1  and  f  and 
z  to  indicate  the  selected  field.  These  values  will  be  reported  to  the  host  in  the  CCO  if  WAVAR  is 
relinquished  in  reaction  to  this  FEE.  Violation  of  this  FEI  will  occur  if  an  attempt  is  made  to  change  the 
primary  or  secondary  attribute  of  any  array  element  of  this  field. 


8.3.5.2        Echo  Specified  Character 

Specifies  the  character  which  is  to  be  echoed  to  the  user  in  response  to  each  allowed  character  entered 
into  the  field.  The  secondary  attributes  of  the  echoed  character  may  be  specified.  Any  secondary  attribute 
that  is  not  given  an  explicit  value  in  the  FEI  takes  a  default  value  in  accordance  with  Definitive  Note  4.  This 
FEI  can  never  be  violated. 


8.3.5.3         Minimum  Entry 

All  array  elements  k  =  1  through  k= Minimum  Entry  must  have  a  primary  attribute.  If  Minimum  Entry  exceeds 
field  size,  then  all  positions  in  the  field  must  be  filled.  Violation  of  this  FEI  will  occur  if  any  of  the  specified 
array  elements  are  empty  when  one  of  the  reactions  FER01  (Transmit  updates)  or  FER02  (Relinquish 
WAVAR)  is  initiated.  See  also  the  specification  of  these  reactions  given  below.  When  a  field  is  associated 
with  both  the  Optional  Field  FEI  and  a  Minimum  Entry  FEI,  the  field  is  optional  but  if  entry  is  elected,  the 
number  of  characters  specified  by  the  Minimum  Entry  FEI  must  then  be  entered. 


8.3.5.4        Allowed  First  Characters 

Specifies  a  set  of  allowed  characters  for  the  first  character  position  of  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3. 


8.3.5.5        Allowed  Characters 

Specifies  a  set  of  allowed  characters  for  all  character  positions  within  the  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note  3.  If  Allowed  First 
Characters  and  Allowed  Characters  are  both  specified  for  a  particular  field,  then  the  set  of  Allowed  First 
Characters  applies  to  the  first  character  position  of  the  field  and  the  set  of  Allowed  Characters  applies  to 
the  second  through  last  character  positions  of  the  field. 
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Specifies  a  set  of  disallowed  characters  for  all  character  positions  within  a  field.  Either  primary  attributes 
alone  or  both  primary  and  secondary  attributes  may  be  checl<ed;  see  Definitive  Note  3.  If  Allowed  First 
Characters  and  Disallowed  Characters  are  both  specified  for  a  particular  field,  then  the  set  of  Allowed  First 
Characters  applies  to  the  first  character  position  of  the  field  and  the  set  of  Disallowed  Characters  applies 
to  the  second  through  last  character  positions  of  the  field.  When  a  field  is  associated  with  Allowed 
Characters  FEI(s)  and  Disallowed  Characters  FEI(s)  that  have  characters  in  common,  the  common 
characters  are  considered  as  disallowed. 


8.3.5.7        Entry  Invoke  Character 

Specifies  the  attributes  to  be  used  for  showing  or  highlighting  to  the  user  where  the  next  character  entry  is 
to  be  made.  Both  primary  and  secondary  attributes,  or  secondary  attributes  alone,  may  be  specified  to 
over-ride  the  corresponding  values  present  in  the  array  element  concerned.  Any  secondary  attribute  that 
is  not  given  an  explicit  value  in  the  FEI  takes  a  default  value  in  accordance  with  Definitive  Note  4.  Fields 
that  are  not  linked  to  an  Entry  Invoke  Character  FEI,  utilize  a  device  dependent  entry  invoke  character 
which  may  or  may  not  be  represented  in  the  character  repertoire  negotiated  for  the  device.  This  FEI  can 
never  be  violated. 


8.3.5.8        Waiting  Time 

Specifies  the  number  of  seconds  to  wait  for  field  entry  to  complete  after  the  cursor  has  been  positioned 
within  the  field.  Fields  that  are  not  associated  with  a  Waiting  Time  FEI  are  not  subject  to  the  "Field  Waiting 
Time  Expired"  Field  Entry  Event.  Note  that  an  overall  waiting  time  for  an  entire  form  may  be  set  by  use  of 
the  "waiting-time"  control  object  defined  in  Definitive  Note  1 .  This  FEI  can  never  be  violated. 


8.3.5.9        Allowed  String  Values 

Specifies  a  list  of  strings  which  identify  valid  field  values.  The  strings  are  specified  as  either  a  discrete 
OCTET  STRING  or  a  range  of  OCTET  STRING,  or  combination  of  both. 

Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and  a  higher  "value"  OCTET  STRING.  The 
"value"  of  an  OCTET  STRING  is  the  integer  value  derived  from  the  collating  sequence  corresponding  to  the 
repertoire  explicitly  or  implicitly  specified  for  the  OCTET  STRING.  For  example,  the  ISO  646  string  'AB'  has 
the  integer  value  4142(16)  and  the  string  'ABC  has  the  value  414243(16). 

When  strings  of  unequal  length  are  compared,  the  smaller  string  is  filled  on  the  right  with  enough  spaces 
to  make  the  strings  of  equal  length.  The  comparison  of  ISO  646  strings  'AB'  and  'ABC  would  be 
accomplished  by  first  converting  the  string  'AB'  to  'AB'  thus  creating  the  value  414220(16)  to  be  compared 
against  the  value  414243(16).  The  value  of  the  space  character  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field  modal  attributes.  If  this  repertoire  does  not  contain  a 
space,  then  the  value  20(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note 
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3.  A  single  set  of  secondary  attribute  values  may  be  specified  for  eacli  individual  OCTET  STRING  or  range 
of  OCTET  STRINGS. 


8.3.5.10       Allowed  Numeric  Values 

Specifies  a  list  of  numeric  strings  which  identify  valid  field  values.  The  strings  are  specified  as  either  a 
discrete  OCTET  STRING  or  a  range  of  OCTET  STRING,  or  a  combination  of  both. 

Ranges  are  specified  using  a  lower  "value"  OCTET  STRING  and  a  higher  "value"  OCTET  STRING.  The 
"value"  of  an  OCTET  STRING  is  the  integer  value  derived  from  the  collating  sequence  corresponding  to  the 
repertoire  explicitly  or  implicitly  specified  for  the  OCTET  STRING.  For  example,  the  ISO  646  string  '12'  has 
the  integer  value  3132(16)  and  the  string  '123'  has  the  integer  value  313233(16). 

When  strings  of  unequal  length  are  compared,  the  smaller  string  is  filled  on  the  left  with  enough  zero 
characters  to  make  the  strings  of  equal  length.  The  comparison  of  ISO  646  strings  '12'  and  '123'  would  be 
accomplished  by  first  converting  the  string  '12'  to  '012'  thus  creating  the  value  303132(16)  to  be  compared 
against  the  value  313233(16).  The  value  of  the  zero  character  is  derived  from  the  collating  sequence 
corresponding  to  the  repertoire  identified  in  the  field  modal  attributes.  If  this  repertoire  does  not  contain  a 
zero,  then  the  value  30(16)  is  used. 

Either  primary  attributes  alone  or  both  primary  and  secondary  attributes  may  be  checked;  see  Definitive  Note 
3.  A  single  set  of  secondary  attribute  values  may  be  specified  for  each  individual  OCTET  STRING  or  range 
of  OCTET  STRINGS. 


8.3.6       Mutually  Exclusive  FEIs 

Some  FEIs  specify  field  entry  validation  rules  that  are  in  conflict  with  the  rules  specified  by  other  FEIs.  For 
example,  a  particular  field  cannot  be  both  "protected"  and  "mandatory."  Such  conflicting  FEIs  cannot  be 
associated  with  the  same  field.  Table  9  defines  the  sets  of  conflicting  FEIs. 
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Table  9  -  Sets  of  conflicting  FEIs 


FEI 

Conflicting  FEIs 

Optional  Field 

Mandatory  Field,  Selectable  Field,  Protected  Field 

Mandatory  Field 

Optional  Field,  Selectable  Field,  Protected  Field 

Selectable  Field 

All  except  Entry  Invoke  Character  and  Waiting  Time 

Protected  Field 

All 

Fill  Field 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Echo  Received 
Character 

Selectable  Field,  Protected  Field,  Echo  Off,  Echo 
Specified  Character 

Echo  Off 

Selectable  Field,  Protected  Field,  Echo  Received 
Character,  Echo  Specified  Character 

Ignore  Case 

Selectable  Field,  Protected  Field 

Inhibit  Logical 
Rendition 

Attribute  Operation 

Selectable  Field,  Protected  Field 

Echo  Specified 
Character 

Selectable  Field,  Protected  Field,  Echo  Off,  Echo 
Received  Character 

Minimum  Entry 

Selectable  Field,  Protected  Field 

Allowed  First 
Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Allowed  Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Disallowed  Characters 

Selectable  Field,  Protected  Field,  Allowed  String 
Values,  Allowed  Numeric  Values 

Entry  Invoke  Character 

Protected  Field 

Waiting  Time 

Protected  Field 

Allowed  String  Values 

Selectable  Field,  Protected  Field,  Fill  Field, 
Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters,  Allowed  Numeric  Values 

Allowed  Numeric  Values 

Selectable  Field,  Protected  Field,  Fill  Field, 
Allowed  First  Characters,  Allowed  Characters, 
Disallowed  Characters,  Allowed  String  Values 
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In  the  following  syntax,  ASN.1  Value  Assignments  have  been  used  to  attach  value  references  to  values  of 
type  NULL  This  enables  the  values  to  be  referenced  by  these  names  alone,  without  the  need  to  follow  the 
identifier  explicitly  with  the  value  NULL. 

FEI  DEFINITIONS  ::=  BEGIN 


FEI  ::=  CHOICE  { 

feiO 

[0] 

IMPLICIT  NULL, 

fell 

[1] 

IMPLICIT  NULL, 

fei2 

[2] 

IMPLICIT  NULL, 

feiS 

[3] 

IMPLICIT  NULL, 

fei4 

[4] 

IMPLICIT  NULL, 

feiS 

[5] 

IMPLICIT  NULL, 

feiS 

[6] 

IMPLICIT  NULL, 

fei7 

[7] 

IMPLICIT  NULL, 

selectableField 

[8] 

IMPLICIT  SEQUENCE  { 

visit     [0]  IMPLICIT  SecAttributes 
select  [1]  IMPLICIT  SecAttributes 
echoSpecifiedCharacter  [9] 
rrsinimumEntries  [10] 
£  ;wedFirstCharacters  [11] 
aliowedCharacters  [12] 
disallowedCharacters  [13] 
entrylnvokeCharacter  [14] 
[0]  IMPLICIT  Character, 
[1]  IMPLICIT  SecAttributes 


waitingTinne 

allowedStringValues 

allowedNumericValues 


[15] 
[16] 
[17] 


OPTIONAL, 
OPTIONAL  }, 
IMPLICIT  Character, 
IMPLICIT  INTEGER, 
IMPLICIT  CharacterValues, 
IMPLICIT  CharacterValues, 
IMPLICIT  CharacterValues, 
CHOICE  { 

}. 

IMPLICIT  INTEGER, 
IMPLICIT  CharacterValues, 
IMPLICIT  CharacterValues  } 


optionalField 

FEI  : 

=  feiO  NULL 

nnandatoryField 

FEI  : 

=  fell  NULL 

protectedField 

FEI  : 

=  fei2  NULL 

fiilField 

FEI  : 

=  fei3  NULL 

echoReceivedChar 

FEI  : 

=  fei4  NULL 

echoOff 

FEI  : 

=  feiS  NULL 

ignoreCase 

FEI  : 

=  fei6  NULL 

inhibltLogRendAttOp 

FEI  : 

=  felT  NULL 

Character  ::=  SEQUENCE  { 

primaryValue  [0]      IMPLICIT  PriValue, 
attributes       [1]      IMPLICIT  SecAttributes  OPTIONAL } 
-  When  used  as  one  element  of  a  comparison,  secondary 
--  attributes  are  to  be  compared  only  if  the  attributes 
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-  element  is  present. 

CharacterValues  ::=  SEQUENCE  OF  SEQUENCE  { 

lowValue  [0]      IMPLICIT  Character, 

highValue  [1]      IMPLICIT  PrIValue  OPTIONAL } 

--  The  default  for  highValue  is  the  associated 

-  lowValue.  Octet  values  specified  for  highValue 

-  are  constrained  by  the  repertoire  corresponding 
--  to  the  lowValue  value.  The  relationship 

--  [lowValue  <  =  highValue]  must  be  true. 

PriValue  ::=  OCTET  STRING 

-  The  octet  string  comprising  a  value  of  the  PriValue 
--  type  is  constrained  to  the  encoding  of  a  sequence 
--  of  characters  from  the  repertoires  negotiated  for 

--  the  associated  Display  Object.  When  used  in  the 

-  ASN.1  module  FEI,  the  octet  string  is  restricted  to 
--  the  encoding  of  a  single  character  except  for  its 

--  use  in  allowedStringValues  and  allowedNumeric- 
--  Values. 

SecAttributes  ::=  SEQUENCE  { 


repertoire 

[0] 

IMPLICIT  INTEGER  OPTIONAL, 

foregroundColour 

[1] 

IMPLICIT  INTEGER  OPTIONAL, 

backgroundColour 

[2] 

IMPLICIT  INTEGER  OPTIONAL, 

emphasis 

[3] 

IMPLICIT  PrintableString  OPTIONAL, 

font 

[4] 

IMPLICIT  INTEGER  OPTIONAL  } 

END  *(FEI  DEFINITIONS)* 

8.3.8       FEICO  "mandatory-feico "  Initial  Content 

For  each  FEIRxx,  xx  Identifies  the  integer  value  to  be  used  as  "feirList  recordlndex"  in  FDCOUpdate 
operations.  FEICOUpdate  operations  must  use  an  "index"  greater  than  127.  Note  that  the  character 
oriented  FEIRs  for  the  initial  FEICO  utilize  the  default  secondary  attributes,  and  that  the  Selectable  Field  FEI 
uses  implementation-dependent  defaults  for  the  'visit'  and  'select'  secondary  attributes.  The  FEIR  contents 
are  specified  in  terms  of  ASN.1  Value  Notation  appropriate  to  the  FEICO  Update  Syntax  specified  above. 


Table  10  -  FEICO  "mandatory-feico'  Initial  Content 


FEIR 

Value 

FEIROO 

—  not  used  — 

FEIROl 

optionalField 

FEIR02 

mandatoryField 

FEIR03 

selectableField  {  ) 
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FEIR04 

protGCtedFi eld 

FEIR05 

f illField 

FEIR06 

echoReceivedCharacter 

FEIR07 

echoOf f 

FEIR08 

ignoreCase 

FEIR09 

inhibitLogRendAttOp 

FEIRIO 

allowedCharacters  {{ 
highValue  '5A'H  }}  — 

lowValue  { • 
Af , , , fZ 

41'H), 

FEIRll 

allowedCharacters  {{ 
highValue  '7A'H  )}  — 

lowValue  { ' 
a,b, . . . ,z 

61'H}, 

FEIR12 

allowedCharacters  {{ 
highValue  '39'H  }}  — 

lowValue  { ' 
0,1, ...  ,9 

30 'H} , 

FEIR13 

disallowedCharacters 
highValue  '5A'H  }}  — 

r  r   1      TT  1 
I {  lowValue 

A,B,...,Z 

{'41'H}, 

FEIR14 

disallowedCharacters 
highValue  '7A'H  }}  ~ 

{{  lowValue 
a,lD,  • .  •  ,z 

{•61'H}, 

FEIR15 

disallowedCharacters 
highValue             )}  — 

{{  lowValue 
0,1,. ..,9 

{'30'H}, 

FEIR16-FEIR127 

—  These  values  are  reserved  — 

8.3.9       Field  Entry  Event  Definitions 

The  Field  Entry  Events  for  the  mandatory  FEPCO  are  defined  in  the  following  subclauses.  A  parameter  of 
type  "Range"  is  a  sequence  of  integer  pairs,  each  with  an  optional  bitmask.  Each  pair  gives  the  end  points 
of  an  interval  of  integer  values.  An  integer  value  lies  within  the  range  specified  if,  after  applying  the  bitmask 
(if  given)  to  its  binary  form,  it  lies  in  any  of  these  intervals.  The  end  points  of  an  inten/al  are  included  in  the 
values  of  that  interval. 

It  is  permissible  for  the  ranges  specified  by  the  FEEs  referenced  in  the  entry  control  FEPR-list  of  a  field  to 
overlap.  When  an  event  occurs  which  is  referenced  in  this  way  by  more  than  one  FEPR  linked  to  the  current 
field,  the  FEPR  invoked  is  the  first  FEPR  in  the  FEPR-list  which  both  references  the  event  and  for  which  the 
Field  Entry  Conditions  are  satisfied. 


8.3.9.1  FEEOO 

Not  used. 
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8.3.9.2        FEE01  Logical  Keystroke  event  (Range) 

This  event  takes  a  range  of  integers  as  a  parameter,  and  occurs  when  a  Logical  Keystroke  occurs  within 
the  specified  range.  The  Logical  Keystroke  is  either  initiated  by  the  Logical  Keystroke  FER  or  by  the  hunnan 
user,  see  Definitive  Note  8. 


8.3.9.3        FEE02  Field  entry  complete 

This  event  is  generated  by  entry  of  a  character  Into  the  last  position  In  a  field.  It  need  not  Imply  that  all 
character  positions  in  the  field  have  been  entered,  since  these  positions  are  not  necessarily  written 
sequentially.  Local  cursor  movements,  for  example,  may  be  used  during  local  editing  to  move  the  current 
entry  position  around  the  screen. 


8.3.9.4        FEE03  Field  selected 

This  event  is  generated  by  the  selection  of  a  field  that  is  linked  to  the  Selectable  Field  FBI.  The  means  by 
which  the  current  candidate  for  selection  is  actually  selected  is  implementation  dependent. 


8.3.9.5        FEE04  Field  Waiting  Time  expired 

The  field  waiting  time  specified  by  the  Waiting  Time  FEI  linked  to  the  current  field  has  been  exceeded. 
Fields  not  linked  to  such  an  FEI  are  not  subject  to  this  event. 


8.3.9.6        FEE05  Field  Entry  Instruction  violation 

Some  of  the  defined  FEIs  imply  Field  Entry  Validation  by  the  terminal  VT-user.  Fields  linked  to  such  FEIs 
are  candidates  for  erroneous  field  entry.  This  event  is  generated  when  such  a  violation  occurs,  thus 
enabling  linkage  to  Field  Entry  Reactions  that  may  signal  a  visual  or  audible  indication  of  such  a  violation, 
or  alternatively  may  terminate  local  entry  and  relinquish  WAVAR.  A  Violation  FEC  is  available  to  allow 
different  reactions  according  to  which  FEIR  is  violated.  When  the  reaction  is  to  relinquish  WAVAR,  the  Entry- 
control  index  and  FEPR  Index  elements  of  the  Context  Control  Object  will  inform  the  host  which  FEPR 
caused  the  return.  If  this  FEPR  has  made  use  of  the  Violation  FEC,  this  FEC  will  identify  to  the  host  that  the 
violated  FEIR  was  one  of  those  in  the  list  that  forms  the  parameter  value  for  the  FEC.  Unique  Identification 
of  the  FEIR  Is  obtained  if  this  list  contains  only  one  FEIR.  The  host  can  then  take  whatever  action  is 
appropriate  to  the  FEIR  or  FEIRs  so  Identified. 


8.3.10      Field  Entry  Condition  Definitions 

The  elementary  Field  Entry  Conditions  for  the  mandatory  FEPCO  are  defined  below.  Composite  conditions 
can  be  built  by  use  of  the  specified  parameters,  and  an  individual  FEPR  can  include  multiple  conditions  in 
accordance  with  20.3.5.2  of  ISO  9040. 
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A  parameter  of  type  Action  is  specified  either  as  an  explicit  integer  value  or  as  the  current  keystroke,  see 
Definitive  Note  8.  Such  a  paranneter  evaluates  to  an  integer  of  the  type  STCO.Key  defined  in  clause  7.3.7. 
That  clause  also  defines  names  of  logical  keystrokes  associated  with  these  integers.  The  local  actions 
associated  with  such  values  are  defined  in  Definitive  Note  9. 


8.3.10.1  FECOO 

Not  used. 


8.3.10.2       FEC01  No  previous  field 

The  current  field  has  no  currently  defined  previous  field,  in  the  sense  of  20.3.3.4  of  ISO  9040. 


8.3.10.3  FEC02  No  next  field 

The  current  field  has  no  currently  defined  next  field,  in  the  sense  of  20.3.3.4  of  ISO  9040. 

8.3.10.4  FEC03  Start  of  field 

The  current  location  for  the  next  character  entry  is  at  the  first  location  in  the  current  field. 


8.3.1 0.5  FEC04  End  of  field 

The  current  location  for  the  next  character  entry  is  at  the  last  location  in  the  current  field. 

8.3.1 0.6  FEC05  At  tab  stop 

The  current  location  for  the  next  character  entry  is  at  a  tabulation  stop  defined  by  the  optional  Horizontal 
Tabulation  CO  {ewos-vt-co-misc-ht}  registered  with  the  EWOS  Registration  Authority.  If  this  CO  is  not 
present  in  the  VTE,  this  condition  is  deemed  to  be  always  satisfied. 


8.3.10.7       FEC06  At  characters  (Set  of  character  values) 

The  current  location  for  the  next  character  entry  is  at  an  array  element  whose  current  value  is  one  of  the 
specified  characters.  The  set  of  characters  is  specified  and  interpreted  in  accordance  with  Definitive  Note 
3. 
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8.3.10.8       FEC07  Exits  field  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  field. 


8.3.10.9       FEC08  Exits  forward  path  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  fon/vard  navigation  path  starting  at  the  current  field. 


8.3.10.10      FECOg  Exits  backward  path  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  backward  navigation  path  starting  at  the  current  field. 


8.3.10.11      FEC10  Exits  x-array  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  x-array. 


8.3.10.12      FEC11  Exits  y-array  (Action) 

The  local  action  designated  by  the  parameter  value  would  move  the  location  for  the  next  character  entry 
out  of  the  current  y-array. 


8.3.10.13  FECI  2  Not  FEC  (FEC) 

This  condition  is  satisfied  precisely  when  the  FEC  given  as  its  parameter  is  not  satisfied. 

8.3.1 0.1 4  FECI  3  And  FECs  (Set  of  FEC) 

This  condition  is  satisfied  when  each  of  the  conditions  in  the  set  comprising  its  parameter  is  satisfied. 

8.3.1 0.1 5  FECI  4  Or  FECs  (Set  of  FEC) 

This  condition  is  satisfied  when  at  least  one  of  the  conditions  in  the  set  comprising  its  parameter  is  satisfied. 
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8.3.10.16      FECI  5  Violation  (Set  of  FEIR  Identifiers) 

This  condition  is  provided  for  use  in  conjunction  with  the  Field  Entry  Instruction  Violation  FEE.  Its  parameter 
is  an  FEIR-list  specified  as  a  set  of  FEIR  identifiers.  Each  identifier  is  a  pair  <FEICO-name,  index>  where 
index  is  an  integer  addressing  a  record  in  the  FEICO  whose  name  is  specified.  This  FEC  is  satisfied  if  the 
FEIR  whose  violation  generated  this  event  is  one  of  the  FEIRs  in  this  FEIR-list.  If  it  is  used  in  conjunction 
with  any  other  FEE  then  this  condition  is  true. 


8.3.10.17      FECI  6  Unconditional 

This  condition  is  always  true.  It  is  given  for  completeness  only,  and  has  the  same  effect  as  an  empty  set 
of  conditions  in  an  FEPR. 


8.3.11      Field  Entry  Reaction  Definitions 

The  Field  Entry  Reactions  for  the  mandatory  FEPCO  are  defined  below.  The  significance  of  a  parameter 
of  type  "Action"  is  as  described  for  Field  Entry  Conditions.  A  parameter  of  type  "ResetAttribute"  may  take 
either  of  the  two  values  "reset"  and  "noReset."  Such  a  parameter  controls  the  effect  of  an  erase  operation 
on  the  secondary  attributes  of  the  erased  elements,  corresponding  to  the  values  "yes"  and  "no"  for  the  reset- 
attribute  parameter  of  a  LOGICAL-ERASE  operation  as  defined  in  19.2.3.5  of  ISO  9040. 


8.3.11.1  FEROO 

Not  used. 


8.3.11.2       FER01  Transmit  updates 

The  host  copy  of  the  CCA  is  updated  to  correspond  to  the  terminal  copy  by  the  transmission  of  all 
undelivered  update  operations.  The  operations  required  to  update  field  contents  are  controlled  by  the  T- 
policy  component  of  the  Field  Definition  Record  for  the  fields  concerned.  However,  if  this  FER  generates 
an  FEI  violation  in  accordance  with  the  specifications  of  the  FEICO(s)  present  in  the  VTE,  and  if  the  current 
field  is  also  linked  to  an  FEPR  with  event  FEEDS  (FEI  violation)  and  satisfied  conditions,  then  this  FER  is  not 
performed  and  that  FEPR  is  activated;  the  original  FEPR  is  abandoned. 


8.3.1 1 .3       FER02  Relinquish  WAVAR 

The  action  described  under  Transmit  Updates  is  performed,  followed  by  return  of  the  WAVAR  access  right 
to  the  host.  However,  if  this  FER  generates  an  FEI  violation  in  accordance  with  the  specifications  of  the 
FEICO(s)  present  in  the  VTE,  and  if  the  current  field  is  also  linked  to  an  FEPR  with  event  FEE05  (FEI 
violation)  and  satisfied  conditions,  then  this  FER  is  not  performed  and  that  FEPR  is  activated;  the  original 
FEPR  is  abandoned. 
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The  primary  attribute  value  is  cancelled  for  all  elements  of  the  current  field  from  the  current  character  entry 
location  to  the  end  of  the  field.  The  effect  on  the  secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  described  above. 


8.3.11.5       FER04  Erase  path  right  (Reset  attribute) 

The  primary  attribute  value  is  cancelled  for  all  elements  of  all  unprotected  fields  in  the  forward  navigation 
path  containing  the  current  field,  from  the  current  character  entry  location  onwards.  Note  that  the  forward 
navigation  path  may  not  terminate,  as  its  definition  in  20.3.3.4  of  ISO  9040  does  not  prohibit  looping.  When 
a  loop  is  entered  during  this  operation,  the  operation  terminates  when  all  elements  of  the  entered  loop  have 
been  erased.  The  effect  of  this  operation  on  the  secondary  attribute  values  is  determined  by  the  reset- 
attribute  parameter  as  described  above. 


8.3.11.6       FER05  Local  action  (Action) 

That  local  action  is  performed  which  is  designated  by  the  given  parameter  value.  The  specification  of  these 
local  actions  is  given  in  Definitive  Note  9. 


8.3.11.7       FER06  Logical  Keystroke  (Action) 

Initiate  the  FEPR  processing  which  v^^ould  occur  if  the  given  l<eystrol<e  had  occurred.  This  may  itself  cause 
the  Logical  Keystroke  FER  and  hence  recursive  processings  of  FERs.  Processing  of  current  FERs  is 
suspended  until  this  recursive  processing  is  complete.  During  recursive  processing,  the  current  l<eystroke 
is  taken  as  the  argument  to  this  FER.  When  the  recursive  processing  is  complete,  the  previous  keystroke 
is  restored  and  processing  of  current  FERs  is  resumed. 


8.3.11.8       FER07  Update  ST  CO  (Action) 

The  integer  value  corresponding  to  the  given  parameter  is  written  to  the  Sequenced  Terminal  CO.  This  FER 
will  usually  be  followed  by  a  Transmit  Updates  or  Relinquish  WAVAR  FER  to  communicate  the  update  to  the 
application. 


8.3.1 1 .9       FER08  Update  UT  CO  (Action) 

The  integer  value  corresponding  to  the  given  parameter  is  written  to  the  Unsequenced  Terminal  CO.  This 
update  will  be  communicated  to  the  application  immediately. 
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8.3.11.10      FER09  Execute  RIO  record  (RIO  record  id) 

An  EXECUTE-RECORD  operation  is  performed  on  the  RIO  record  specified  in  the  parameter,  in  accordance 
with  22.4.1  of  ISO  9040. 


8.3.11.11      FER010  Call  RIO  record  (RIO  record  Id) 

A  CALL-RECORD  operation  is  performed  on  the  RIO  record  specified  in  the  parameter,  in  accordance  with 
22.4.2  of  ISO  9040. 


8.3.11.12      FER11  Visual  indication 

Present  a  visual  indication  in  response  to  Field  Entry  Instruction  violations. 


8.3.1 1.13      FER1 2  Audible  indication 

Present  an  audible  indication  in  response  to  Field  Entry  Instruction  violations. 


8.3.1 1.14      FER1 3  Conditional  branch 

(if:  FEC,  then:  Optional  sequence  of  FER,  else:  Optional  sequence  of  FER) 

If  the  condition  given  by  the  "if"  parameter  is  satisfied  then  perform  the  sequence  of  reactions  given  by  the 
"then"  parameter,  else  perform  the  sequence  of  reactions  given  by  the  "else"  parameter. 


8.3.1 1.15      FER1 4  Prevent  further  entry 

It  is  recommended  that  if  a  type-ahead  buffer  is  in  use  by  the  local  user  interface,  this  reaction  should 
prevent  further  entry  into  the  buffer.  Attempted  entry  may  then  sound  an  alarm  or  be  signalled  by  some 
other  local  means,  but  is  not  an  FEI  violation.  If  the  WAVAR  access  right  is  relinquished  without  this  reaction 
being  invoked,  the  buffer  may  continue  to  accept  entries.  Entry  into  the  buffer  is  resumed  when  WAVAR 
is  next  returned  to  the  terminal.  It  is  not  a  violation  of  this  profile  specification  if  the  terminal  VT-user  does 
not  behave  in  the  intended  manner. 


8.3.1 1.16      FER1 5  Write  disallowed  character 

The  most  recent  disallowed  character  is  written  as  if  it  were  not  disallowed.  If  there  has  been  no  disallowed 
character,  the  effect  is  null.  This  FER  is  used  when  it  is  desired  to  trap  the  entry  of  a  particular  character, 
not  to  forbid  it  but  instead  to  generate  some  other  reactions  in  addition  to  the  character  entry. 
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8.3.1 1 .1 7      FER1 6  Write  string  (Character  string) 

The  character  string  given  as  a  parameter  is  written  as  LOGICAL  TEXT  to  the  current  entry  location  without 
regard  to  FEICO  control.  If  the  end  of  the  field  is  reached  before  the  string  has  been  written  in  its  entirety, 
the  reaction  is  terminated  prematurely. 


8.3.12      Field  Entry  Pilot  Update  Syntax 

In  the  following  syntax,  ASN.1  Value  Assignments  have  been  used  to  attach  value  references  to  values  of 
type  NULL.  This  enables  the  values  to  be  referenced  by  these  names  alone,  without  the  need  to  follow  the 
identifier  explicitly  with  the  value  NULL. 


FEPR  DEFINITIONS  ::=  BEGIN 


FEE  ::=  CHOICE  { 

logicalKeystroke 


[1] 
[2] 
[3] 
[4] 
[5] 


IMPLICIT  Range, 
IMPLICIT  NULL, 
IMPLICIT  NULL, 
IMPLICIT  NULL, 
IMPLICIT  NULL  } 


fee02 
feeoa 
fee04 
fee05 


fieldEntryConnplete  FEE 
fieldSelected  FEE 
fieldWaitTimeExpired  FEE 
feiViolation  FEE 


=  fee02  NULL 
=  fee03  NULL 
=  fee04  NULL 
=  fee05  NULL 
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FEC  ::=  CHOICE  { 

fec01 

[1]  IMPLICIT  NULL, 

fec02 

[2]  IMPLICIT  NULL, 

fec03 

[3]  IMPLICIT  NULL, 

fec04 

[4]  IMPLICIT  NULL, 

fec05 

[5]  IMPLICIT  NULL, 

atChar 

[6]  IMPLICIT  FEI.CharacterValues, 

exitsField 

[7]  Action, 

exits  Forward  Path 

[8]  Action, 

exitsBackward  Path 

[9]  Action, 

exitsXarray 

[10]  Action, 

exitsYarray 

[11]  Action, 

not 

[12]  FEC, 

ana 

[1*51  IMPI  IPIT  QFH"  HP  PPP 

or 

[14]  IMPLICIT  SET  OF  FEC, 

violation 

[15]  IMPLICIT  SET  OF  SEQUENCE 

{  feicoName  PrintableStrinc 

recordlndex    INTEGER  }, 

fed  6 

[16]  IMPLICIT  NULL  } 

noPreviousField 

FEC  ::=  fecOl  NULL 

noNextField 

FEC  ::=  fec02  NULL 

startField 

FEC  ::=  fec03  NULL 

endField 

FEC  ::=  fec04  NULL 

atTab 

FEC  ::=  fec05  NULL 

unconditional 

FEC  ::=  fec16  NULL 
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FER  ::=  CHOICE  { 
fer01 
fer02 

eraseFieldRight 
erasePathRight 
local 

logicalKeystroke 
updateSTCO 
updateUTCO 
executeRIO 
callRIO 
fer11 
fer12 
branch 

if 

then 
else 

fer14 
fer15 

writeString 


[I]  IMPLICIT  NULL, 
[2]  IMPLICIT  NULL, 

[3]  IMPLICIT  ResetAttribute, 
[4]  IMPLICIT  ResetAttribute, 
[5]  Action, 
[6]  Action, 
[7]  Action, 
[8]  Action, 

[9]  IMPLICIT  RIORecordID, 
[10]  IMPLICIT  RIORecordID, 

[II]  IMPLICIT  NULL, 
[12]  IMPLICIT  NULL, 


[13]  IMPLICIT  SEQUENCE  { 
[1]  FEC, 

[2]  IMPLICIT  SEQUENCE  OF  FER  OPTIONAL, 
[3]  IMPLICIT  SEQUENCE  OF  FER  OPTIONAL  }, 
[14]  IMPLICIT  NULL, 
[15]  IMPLICIT  NULL, 
[16]  IMPLICIT  SEQUENCE  OF 
FEI. Character 

-  The  string  written  by  this  FER  is  the 

-  concatenation  of  the  strings  specified  by 

-  the  individual  FEI. Character  values.  --  } 


transmitUpdates 

FER  : 

:=  fer01 

NULL 

relinquishWAVAR 

FER  : 

:=  fer02 

NULL 

visuallndication 

FER  : 

:=  fern 

NULL 

audiblelndication 

FER  : 

:=  fer12 

NULL 

preventFurtherEntry 

FER  : 

:=  fer14 

NULL 

writeDisallowedChar 

FER  : 

:=  fer15 

NULL 

RIORecordID  ::=  SEQUENCE  { 

rioName  [1]  IMPLICIT  PrintableString  OPTIONAL, 

--  optional  if  there  is  only  1  RIO  in  the  VTE 
recordID  [2]  IMPLICIT  PrintableString  } 


Range  ::=  SEQUENCE  OF  SEQUENCE  { 

[1]  IMPLICIT  STCO.Key, 
[2]  IMPLICIT  STCO.Key  OPTIONAL, 
mask  [3]  IMPLICIT  BIT  STRING  OPTIONAL  } 

--  The  first  two  values  of  each  trio  represent  an 
--  interval  of  logical  keystroke  values.  The  second 
--  value  in  each  pair  shall  not  be  smaller  than  the 
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--  first  value.  If  the  second  value  is  omitted,  the 
--  interval  contains  only  the  specified  first  value. 
--  If  the  optional  mask  is  given,  then  the  value  being 
-  tested  is  bitwise  logically  ANDed  with  the  mask 
--  before  being  compared  with  the  end  points  of  the 
--  interval. 


ResetAttribute  ::=  BOOLEAN 

reset  ResetAttribute  ::=  TRUE 

noReset  ResetAttribute  ::=  FALSE 

Action  ::=  CHOICE  { 

[1]  IMPLICIT  STCO.Key, 
current  [2]  IMPLICIT  NULL  } 

currentKeystroke  Action  ::=  current  NULL 

--  The  ASN.1  module  STCO  is  defined  in  the  specification  of 
--  the  Sequenced  Terminal  CO  in  clause  7.3.  STCO.Key  is 

an  integer  type  with  a  named  number  list,  each  named 
--  number  representing  a  specific  logical  keystroke  as 
--  defined  for  that  CO. 


END  *(FEPR  DEFINITIONS)* 


FEPCO  "mandatory-fepoo"  Initial  Content 

For  each  FEPRxx,  xx  identifies  the  integer  value  to  be  used  as  "feprList  recordlndex"  in  FDCOUpdate 
operations.  FEPCOUpdate  operations  must  use  an  "index"  greater  than  127.  The  FEPR  contents  are 
specified  in  terms  of  ASN.1  Value  Notation  appropriate  to  the  FEPCO  Update  Syntax  specified  above.  Note 
that  "shiftTab"  is  a  named  integer  of  type  STCO.Key.  The  local  action  it  designates  is  defined  in  Definitive 
Note  9  to  be  movement  of  the  current  character  entry  position  to  the  first  location  of  the  next  field  in  the 
forward  navigation  path. 
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Table  11  -  FEPCP  "mandatory-fepco"  Initial  Content 


FEFR  No 

Component 

ASN.l  Description 

FEPROO 

— Not  used — 

r  CiFKUl 

FEE 

iogicaiKeystroKe  i  I  u,  bbbJb  j  j 

FEC 

uncond  i  t  i  ona 1 

FEROl 

updateSTCO  currentKeystroke 

FER02 

r  e  1  i  nqu  i  s  h  WAVAR 

FEPR02 

FEE 

f ieldEntryComplete 

FEC 

noNextField 

FER 

r e 1 i nqu i s h WAVAR 

FEPR03 

FEE 

f ieldEntryComplete 

FEC 

not  noNextField 

FER 

local  shiftTab 

FEPR04 

FEE 

f ieldSelected 

FEC 

unconditional 

FER 

r el i  nqu  i  shWAVAR 

FEPR05 

FEE 

f ieldWaitTimeExpired 

FEC 

noNextField 

FER 

r e 1 i nqu i s h WAVAR 

FEPR06 

FEE 

f ieldWaitTimeExpi  red 

FEC 

not  noNextField 

FER 

local  ShiftTab 

FEPR07 

FEE 

f eiViolation 

FEC 

unconditional 

FER 

visual Indication 

FEPR08 

FEE 

f eiViolation 

FEC 

unconditional 

FER 

audiblelndication 

FEPR09- 

—  Reserved  — 

FEPR127 

8.3.13      Profile  Arguments 

n  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  x-bound.  it  tai<es  an 
integer  value  greater  than  zero.  Default  is  80. 

r2  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  y-bound.  It  takes  an 
integer  value  greater  than  zero.  Default  is  24. 

r3  -    is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  z-window.  It  takes  an 
integer  value  greater  than  zero.  Default  is  1. 

r4  -    is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  repertoire-assignment.     The  value  for  the  VTE-parameter 
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repertoire-capability  is  implied  by  the  number  of  occurrences  of  this  profile  argument.  Default  is  a 
single  occurrence  with  the  value  {value  iso2022  {'2842'H}}  of  ASN.1  type 
CDS.RepertoireAssignment  as  defined  in  ISO  9041 ,  designating  the  GL  set  ISO  2375  Reg.  No.  6 
(ASCII). 

r5  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  font-assignment.  The  font-assignment-type  component  of  a  font- 
assignment  value  is  an  ASN.1  OBJECT  IDENTIFIER  that  designates  a  registered  syntax  and 
semantics  for  the  font-assignment-value  component.  The  value  for  the  VTE-parameter  font-capability 
is  implied  by  the  number  of  occurrences  of  this  profile  argument.  If  there  are  no  explicit 
occurrences  of  this  profile  argument  then  the  font-capability  and  font-assignment  VTE-parameters 
take  the  default  values  specified  in  ISO  9040. 

r6  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  DO-emphasis.  The  syntax  and  semantics  for  this  VTE-parameter  are 
specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified  in  B.I  7.4  of  ISO  9040.  The 
default  value  for  the  occurrence  corresponding  to  each  unspecified  subattribute  is  the  ASN.1 
PrintableString  of  length  1  specifying  the  explicit  modal  default  value  for  that  subattribute. 

r7  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameters 
foreground-colour-capability  and  background-colour-capability.  Default  is  8.  This  argument  is 
identified  by  the  identifier  for  the  VTE-parameter  foreground-colour-capability  for  display  object  A. 

r8  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  foreground-colour-assignment.  The  default  values  for  unspecified 
occurrences  of  this  profile  argument  are  the  corresponding  values  from  the  ordered  list  {"white," 
"black,"  "red,"  "cyan,"  "blue,"  "yellow,"  "green,"  "magenta"}.  There  are  no  default  values  if  the  value 
of  the  VTE-parameter  foreground-colour-capability  exceeds  8. 

r9  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  background-colour-assignment.  The  default  values  for  unspecified 
occurrences  of  this  profile  argument  are  the  corresponding  values  from  the  ordered  list  {"black," 
"white,"  "cyan,"  "red,"  "yellow,"  "blue,"  "magenta,"  "green"}.  There  are  no  default  values  if  the  value 
of  the  VTE-parameter  background-colour-capability  exceeds  8. 

rIO  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  max-field-elements. 
Default  is  1 . 

r1 1  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  access-outside-fields. 
Default  is  "not  allowed." 

r12  -  is  mandatory  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter  CO-access  for  the 
Field  Definition,  Field  Entry  Instruction,  Field  Entry  Pilot,  Transmission  Policy,  Sequenced 
Application,  Unsequenced  Application,  Sequenced  Terminal,  and  Unsequenced  Terminal  control 
objects.  If  the  VT-association  initiator  is  the  terminal  VT-user,  it  takes  the  value  "WACA,"  otherwise 
it  takes  the  value  "WACI."  This  argument  is  identified  by  the  identifier  for  CO-access  for  control 
object  UA. 
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r13  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  a  value  for  tlie  VTE- 
parameter  CO-name  for  optional  registered  COs.  By  default  no  optional  COs  are  invoked. 

r14  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  a  value  for  the  VTE- 
parameter  CO-type-identifier  for  optional  registered  COs.  The  particular  generic  type  concerned  is 
determined  from  the  CO-type-identifier  by  the  register  entry.  The  value  vt-b-sco-nullrio  selects  an 
empty  RIO.  An  occurrence  of  the  previous  argument  specifies  the  presence  of  an  optional  CO  in 
the  VTE-profile.  An  occurrence  of  this  argument  is  required  for  every  occurrence  of  the  previous 
argument.  By  default  no  optional  COs  are  invoked. 

r15  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-repertoire-assignment  for  the  main  device.  Default  is  "null" 
for  each  unspecified  occurrence. 

r16  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-font-assignment  for  the  main  device.  Default  is  "null"  for  each 
unspecified  occurrence. 

r17  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-emphasis  for  the  main  device.  The  syntax  and  semantics  for 
this  VTE-parameter  are  specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified  in 
B.17.4  of  ISO  9040.  Default  is  "null"  for  each  unspecified  occurrence. 

r18  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-foreground-colour-assignment  for  the  main  device.  Default 
is  "null"  for  each  unspecified  occurrence. 

r19  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-background-colour-assignment  for  the  main  device.  Default 
is  "null"  for  each  unspecified  occurrence. 

r20  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-X-array-length  for  the  main  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  x-bound  for  the  display  object. 

r21  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-Y-array-length  for  the  main  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  y-bound  for  the  display  object. 

r22  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  additional  values  for 
the  VTE-parameter  device-control-object  for  the  main  device.  By  default  there  are  no  additional 
values. 

r23  -  is  a  special  profile  argument  identified  by  the  special-profile-arg-ident  "Pp-1 ."  It  is  optional  and 
provides  for  the  negotiation  of  a  printer  device.  Default  is  "false." 

r24  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-repertoire-assignment  for  the  printer  device.  Default  is  "null" 
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for  each  unspecified  occurrence. 

r25  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-font-assignment  for  the  printer  device.  Default  is  "null"  for  each 
unspecified  occurrence. 

r26  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-emphasis  for  the  printer  device.  The  syntax  and  semantics 
for  this  VTE-parameter  are  specified  in  Definitive  Note  6,  and  for  this  profile  argument  are  specified 
in  B.17.4  of  ISO  9040.  Default  is  "null"  for  each  unspecified  occurrence. 

r27  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-foreground-colour-assignment  for  the  printer  device.  Default 
is  "black"  for  each  unspecified  occurrence. 

r28  -  is  optional,  may  occur  a  number  of  times  in  an  ordered  list  and  provides  for  the  negotiation  of  a 
value(s)  for  the  VTE-parameter  device-background-colour-assignment  for  the  printer  device.  Default 
is  "white"  for  each  unspecified  occurrence. 

r29  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-X-array-length  for  the  printer  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  x-bound  for  the  display  object. 

r30  -  is  optional  and  provides  for  the  negotiation  of  a  value  for  the  VTE-parameter 
device-minimum-Y-array-length  for  the  printer  device.  It  takes  an  integer  value  greater  than  zero. 
Default  is  the  value  of  y-bound  for  the  display  object. 

r31  -  is  optional,  may  occur  a  number  of  times  and  provides  for  the  negotiation  of  additional  values  for 
the  VTE-parameter  device-control-object  for  the  printer  device.  By  default  there  are  no  additional 
values. 


8.3.14      Profile  Dependent  Control  Objects 

This  profile  uses  the  OIW  registered  Control  Objects  SA,  UA,  ST  and  UT.  The  profile  defined  values  are 
specified  in  the  body  of  this  profile.  The  CO  specifications  require  the  usage  of  each  CO  to  be  specified 
in  the  profile.  This  is  as  follows. 


8.3.14.1       Sequenced  Application  CO 

This  Control  Object  is  defined  in  7.1.  It  has  CO-category  "symbolic."  Update  of  this  CO  with  the  value 
"audib!e_alarm"  sounds  an  audible  alarm  in  the  terminal.  Update  with  the  value  "visual_alarm"  generates  a 
visual  indication  of  a  signal  from  the  application.  All  other  values  have  no  effect. 
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8.3.14.2       Unsequenced  Application  CO 

This  Control  Object  is  defined  in  7.2.  It  has  CO-category  "symbolic."  Update  of  this  CO  with  the  value 
"audible  alarm"  sounds  an  audible  alarm  in  the  terminal.  Update  with  the  value  "visual  alarm"  generates  a 
visual  indication  of  a  signal  from  the  application.  All  other  values  have  no  effect. 


8.3.14.3       Sequenced  Terminal  CO 

This  Control  Object  is  defined  in  7.3.  It  has  CO-category  "integer."  It  Is  updated  by  the  Update  ST  CO  FER, 
and  may  be  used  to  communicate  uninterpreted  keystrokes  to  the  application. 


8.3.14.4       Unsequenced  Terminal  CO 

This  Control  Object  is  defined  in  7.4.  It  has  CO-category  "integer."  It  is  updated  by  the  Update  UT  CO  FER 
and  is  used  to  communicate  uninterpreted  keystrokes  to  the  application  urgently. 


8.3.15      Profile  Notes 


8.3.15.1       Definitive  Notes 

1 .  The  WT  control  object  provides  a  mechanism  for  the  application  VT-user  to  specify  a  time  in  which 
all  the  fields  of  a  form  must  be  completed.  The  terminal  VT-user  starts  the  timer  at  the  time  when 
it  receives  WAVAR.  If  the  timer  expires,  further  entry  by  the  device  is  stopped,  all  undelivered 
updates  are  transmitted,  and  WAVAR  is  relinquished.  The  undelivered  updates  are  transmitted 
followed  by  an  update  to  this  control  object.  The  WT  update  is  made  using  the  current  value  of  the 
WT  control  object.  The  device-control-object  VTE-parameter  is  used  to  link  this  CO  to  the  input 
device  that  it  controls.  The  data  element  of  this  CO  specifies  the  waiting  time  in  seconds.  A  zero 
value  signifies  that  a  Form  Waiting  Time  is  not  to  be  used.  The  initial  value  of  this  data  element  is 
zero. 

2.  If  there  are  two  or  more  Character-oriented  FEIs  of  the  same  type  associated  with  the  same  field, 
they  are  equivalent  to  a  single  FEI  of  that  type  whose  parameter  is  the  concatenation  of  the 
individual  parameter  values. 

3.  The  following  parameteric  FEIs  and  FECs  defined  in  clause  8.3.4  test  equality  of  characters: 

Allowed  First  Characters  FEI 
Allowed  Characters  FEI 
Disallowed  Characters  FEI 
Allowed  String  Values  FEI 
Allowed  Numeric  Values  FEI 
At  Characters  FEC 
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The  characters  for  each  such  FEI  or  FEC  are  specified  by  a  parameter  that  includes  an  optional  set 
of  secondary  attributes.  If  this  set  is  included,  the  test  is  on  both  primary  and  secondary  attributes; 
othenA/ise  it  is  on  primary  attributes  only.  If  the  test  is  on  primary  attributes  only,  then  characters 
which  pass  the  test  are  allowed,  disallowed  or  accepted,  as  appropriate,  irrespective  of  the  values 
of  their  secondary  attributes.  The  set  of  secondary  attributes  need  not  specify  an  explicit  value  for 
every  secondary  attribute;  in  particular  the  empty  set  is  permissible.  Default  values  are  used  for 
unspecified  secondary  attributes.  These  are  determined  in  accordance  with  Definitive  Note  4. 

4.  The  parameter  values  for  a  number  of  FEIs,  FECs  and  FERs  require  default  values  to  be  used  for 
secondary  attributes  when  such  values  are  not  specified  explicitly  by  the  parameter.  The  first  choice 
default  for  each  secondary  attribute  value  is  the  field  modal  attribute  value  at  the  time  that  the  FEI, 
FEC  or  FER  is  accessed.  A  first  choice  default  value  of  "null"  is  resolved  as  specified  in  19.2.3.1  of 
ISO  9040  for  the  LOGICAL-TEXT  update  operation. 

5.  When  the  Character  oriented  FEIs  associated  with  a  particular  field  have  characters  in  common,  the 
precedence  algorithm  given  below  is  used. 

The  Allowed  First  Characters  FEI  takes  precedence  over  the  Allowed  Characters  and  Disallowed 
Characters  FEIs  for  field  character  position  k=1.The  Disallowed  Characters  FEI  takes  precedence 
over  the  Allowed  Characters  FEI  for  all  field  character  positions. 

The  following  example  illustrates  the  conflict  resolution  algorithm.  When  a  particular  field  is  linked 
to  the  following  three  Character  oriented  FEIs: 

Allowed  First  Characters      =  a 
Allowed  Characters  =  a,b 

Disallowed  Characters         =  a 

the  field  must  be  entered  with  the  letter  "a"  in  the  first  character  position  of  the  field.  The  remaining 
character  positions  in  the  field  are  limited  to  containing  the  letter  "b."  Therefore  field  entry  would 
be  limited  to  a  form  such  as  "abbbb.  ..." 

6.  The  following  syntax  and  semantics  is  mandatory  for  the  emphasis  and  device-emphasis  VTE- 
parameters.  The  scheme  of  B.I 7.3  of  ISO  9040  is  to  be  adopted  except  that  the  maximum  length 
for  an  ASN.1  PrintableString  used  as  an  emphasis  value  is  increased  from  6  characters  to  8 
characters.  Values  "B"  (Boxed)  and  "C"  (Encircled)  are  deleted  from  subattribute  "b."  Two  further 
subattributes  are  added,  denoted  by  "g"  and  "h."  The  table  of  allowed  character  values,  ISO  6429 
SET  GRAPHIC  RENDITION  parameter  values  and  associated  semantics  given  in  B.17.3  of  ISO  9040 
is  augmented  by  the  addition  of: 

Subattribute  "g"  values 

=  1"  3        Italicized  characters 

=  "U"  *         23      Upright,  not  italicized 
characters 

=  " "  -        No  change 

Subattribute  "h"  values 

=  "F"  51  Framed 
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52 
54 


Encircled 

Not  framed,  not  encircled 
No  change 


As  in  B.17.3  of  ISO  9040,  *  indicates  tfie  value  which  is  the  explicit  nnodal  default  value  for  the 
subattribute.  Not  all  the  values  of  this  schenne  need  to  have  a  1-1  correspondence  with  emphasis 
levels  available  on  the  real  device.  The  device  object  defines  the  real  mapping. 

7.  When  default  values  are  defined  for  a  multiple-occurrence  profile  argument  and  fewer  occurrences 
are  negotiated  than  are  required  by  the  value  of  a  parent  VTE-parameter,  the  remaining  occurrences 
still  take  the  specified  default  values. 

8.  Every  action  corresponding  to  the  operation  of  an  object  updating  device  shall  be  assigned  a  non- 
negative  integer  value.  This  value  shall  be  interpreted  as  a  logical  keystroke  in  accordance  with  the 
definitions  of  the  Sequenced  Terminal  CO  and  Unsequenced  Terminal  CO  in  7.3  and  7.4. 

Values  in  the  range  0-255  are  used  to  generate  entry  of  characters  into  the  Display  Object  from  the 
available  repertoires.  Values  greater  than  255  generate  the  Logical  Keystroke  FEE  and  thus  have 
effects  that  are  under  the  control  of  the  FEPCOs  present  in  the  VTE. 

9.  A  minimum  set  of  local  actions  is  defined  within  this  profile,  but  implementors  may  extend  this  as 
required.  A  host  implementation  thus  may  not  know  what  local  action  is  being  over-ridden  when 
it  requests  that  a  particular  logical  keystroke  should  be  notified  to  the  host.  To  prevent  this  from 
limiting  the  capabilities  of  the  terminal,  two  keystroke  combinations  that  differ  only  in  the  inclusion 
or  othen/vise  of  the  ALT  key  are  required  to  have  the  same  potential  local  action.  Host 
Implementations  are  advised  not  to  over-ride  the  action  of  both  such  keystrokes. 

The  defined  minimum  set  of  local  actions  concerns  control  of  the  current  entry  location.  At  any  time 
when  the  terminal  possesses  the  WAVAR  access  right,  there  is  a  well-defined  Display  Object  array 
element  which  is  the  current  candidate  for  update  by  a  character  entry  operation,  as  described  in 
Informative  Note  4.  If  this  element  lies  outside  of  any  field,  or  within  a  protected  field,  update  is 
prohibited  unless  the  negotiated  value  of  the  VTE-parameter  access-outside-fields  is  "yes,"  but  the 
array  element  is  still  defined.  Neither  this  location  nor  that  of  any  cursors  which  the  implementation 
may  use  to  indicate  such  elements  is  recorded  in  the  CCA.  It  is  separate  from  the  current  position 
of  either  the  display  pointer  or  the  logical  pointer,  and  movement  of  this  entry  location  is  a  purely 
local  action. 
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Table  12  -  Local  actions  that  move  entry  location 


Name 

Unshifted  Action 

Shifted  Action 

lef tArrow 

X  =  x-1 

k  =  k-1 

right Arrow 

X  =  x+1 

k  =  k+1 

upArrow 

y  =  y-i 

f  =  f-1,  k  =  1 

downArrow 

y  =  y+i 

f  =  f+1,  k  =  1 

home 

(x,y,z)  =  "start-y" 

(k,f,z)  =  "start-k" 

end 

(x,y,z)  =  "end-y" 

(k,f,z)  =  "end-k" 

pageUp 

z  =  z-1,  x=l,  y=l 

z=z-l,  f=l,  k=l 

pageDovm 

z  =  z+1,  x=l,  y=l 

z  =  z+1,  f  =  1,  k  =  1 

tab 

f  =  next ( f ) ,  k  =  1 

bacJcTab 

f  =  previous (f),  k  =  1 

The  names  given  in  the  first  column  of  Table  12  are  the  identifiers  of  named  integers  of  type 
STCO.Key.  The  ASN.1  module  STCO  is  defined  as  part  of  the  specification  of  the  Sequenced 
Terminal  Control  Object  in  7.3.  These  identifiers  or  the  corresponding  integers  are  used  to 
designate  the  local  actions  specified  in  the  second  column.  If  the  initial  lower  case  letter  of  such 
a  name  is  converted  to  upper  case  and  prefixed  with  "shift"  then  it  designates  the  local  action 
specified  in  the  third  column. 

In  this  table,  is  used  as  an  assignment  operator.  The  unshifted  actions  reference  array  elements 
by  normal  (x,  y,  z)  coordinates  while  the  shifted  actions  reference  them  by  logical  (k,  f,  z) 
coordinates.  The  values  next(f)  and  previous(f)  are  defined  in  19.1.3.2.2  of  ISO  9040,  "start-k"  and 
"end-k"  are  defined  in  19.1.3.5,  and  "start-y"  and  "end-y"  are  defined  in  19.1.1.4  of  ISO  9040. 

If  the  initial  or  final  coordinate  values  are  undefined  then  the  local  action  is  implementation- 
dependent.  However,  a  host  implementation  can  use  the  mandatory  FEPCO  to  control  the  behavior 
in  such  circumstances.  Field  Entry  Conditions  are  provided  to  test  whether  a  particular  local  action 
would  make  the  entry  location  leave  the  current  field  or  navigation  path,  as  defined  in  8.3.10. 

10.  If  the  VTE-parameter  access-outside-fields  takes  the  value  "allowed,"  when  data  entry  terminates, 
the  display  pointer  shall  be  aligned  with  the  current  entry  location  by  an  explicit  or  implicit 
addressing  operation.  In  this  way,  the  value  of  the  display  pointer  notifies  the  application  of  the 
current  entry  location. 

11.  Use  of  the  values  "F"  (Framed)  and  "C"  (Encircled)  for  emphasis  subattribute  "h"  causes  groups  of 
characters  within  a  single  field  which  have  this  subattribute  value  to  be  outlined  by  a  frame.  The 
two  subattributes  differ  only  in  that  the  external  corners  of  the  frame  are  squared  if  value  "F"  is  used 
and  rounded  if  value  "C"  is  used.  An  external  corner  is  where  two  lines  meet  in  a  L  shape,  as 
distinct  from  a  T  junction  and  from  the  intersection  of  two  lines.  The  nature  of  the  external  corner 
is  controlled  by  the  subattribute  value  of  the  array  element  on  the  inside  of  the  corner. 
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More  precisely,  a  character  box  element  is  defined  to  be  within  frame  (f.z)  if  it  is  in  the  field  with 
coordinates  (f,z)  and  has  either  the  framed  or  encircled  attribute.  A  character  box  element  is 
defined  to  be  without  frame  if  either  It  is  not  in  any  field  or  it  does  not  have  either  the  framed  or 
encircled  attribute.  In  the  image  of  a  y-array  on  the  real  device,  a  line  is  drawn  between  two 
adjacent  images  of  character  box  elements  if  they  are  within  different  frames,  or  if  one  is  within  a 
frame  and  one  is  without  frame.  In  addition  if  a  character  box  element  is  within  some  frame,  a  line 
is  drawn  along  any  edge  of  that  element  which  is  not  in  common  with  any  other  character  box 
element,  i.e.,  along  any  edges  which  are  part  of  the  image  of  the  boundary  of  the  Display  Object. 


8.3.15.2       Informative  Notes 

1.  Updates  by  the  application  VT-user  (only  possible  within  the  z-window)  are  not  necessarily 
immediately  imaged  to  the  (human  user  of  the)  terminal  VT-user  unless  the  real  window  of  the 
device  is  currently  positioned  over  such  an  update.  Such  updates  may  move  the  real  window  if  a 
VT-DELIVER  indication  is  received. 

When  WAVAR  is  relinquished  by  the  application  VT-user  the  window  may  be  moved  so  that  the  field 
addressed  by  the  CCO  is  within  the  window. 

Application  VT-user  addressing  operations  that  advance  z  to  a  higher  address  which  is  outside  of 
the  z-window  cause  the  z-window  to  move  and  include  one  or  more  new  y-arrays  for  which  no  fields 
are  defined.  As  the  z-window  moves,  one  or  more  y-arrays  at  lower  addresses  will  no  longer  be 
included  in  the  z-window.  The  field  definition  records  for  such  y-arrays  are  implicitly  deleted. 

2.  Several  of  the  descriptions  of  Field  Entry  Instructions  refer  to  'empty'  array  elements  of  the  Display 
Object.  This  is  to  be  interpreted  in  the  sense  of  13.2  of  ISO  9040.  Note  that  in  this  sense  an  array 
element  containing  a  space  character  is  not  empty.  The  representation  of  an  empty  array  element 
on  the  real  device  is  implementation-dependent,  but  for  this  reason  it  is  recommended  that  the 
representation  used  should  be  distinct  from  that  of  a  space  character. 

3.  The  descriptions  of  a  number  of  Field  Entry  Conditions  refer  to  the  current  field  and  to  the  current 
location  for  the  next  character  entry.  Typically  this  current  location  will  be  indicated  to  the  human 
user  by  a  visible  cursor.  When  this  location  lies  within  a  defined  field,  that  field  is  the  current  field 
and  the  Entry  Invoke  Character  FEI  may  be  used  to  specify  the  nature  of  the  visible  cursor. 
However,  a  terminal  implementation  may  allow  the  visible  cursor  to  be  moved  outside  of  any  defined 
field.  While  this  is  so,  the  representation  of  the  cursor  is  implementation  dependent,  the  current  field 
is  undefined  and  no  FEPRs  are  active. 


8.3.16  Specific  Conformance  Requirements 
For  further  agreement. 
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8.4.1  Introduction 

This  profile  provides  support  for  CCITT  X.3  PAD  compatible  operation. 
The  purpose  of  this  profile  is  two-fold: 

a)  to  provide  a  transitional  environment  for  applications  that  assume  the  availability  of  X.3 
parameters  with  which  to  control  the  behavior  of  the  terminal-system; 

b)  to  facilitate  a  gateway  function  between  ISO-VTP  and  X.3. 

8.4.2  Association  Requirements 

8.4.2.1  Functional  Units 

The  Structured  CO  Functional  Unit  is  mandatory. 
The  Urgent  Data  Functional  Unit  is  optional. 

8.4.2.2  Mode 

This  is  an  A-mode  profile. 


8.4.3       Profile  Body 

Display-objects  = 
{ 
{ 

display-object-name  =  D1, 

DO-access  =  profile-argunnent-r1 , 

dimensions  =  "one", 

x-dimension  = 

{ 

x-bound        =  "unbounded", 
x-addressing  =  "not-permitted", 
x-absolute      =  "no". 
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x-window       =  0 

}. 

repertoire-assignment  =  <ESC>  2/5  2/15  4/2 

*(  VIS  Transparent  Set  )* 

}, 

{ 

display-object-name  =  D2, 

DO-access  =  opposite  of  profile-argument-rl , 

dimensions  =  "one", 

x-dimension  = 

{ 

x-bound        =  "unbounded", 
x-addressing  =  "not-permitted", 
x-absolute      =  "no", 
x-window       =  0 

}, 

repertoire-assignment  =  <ESC>  2/5  2/15  4/2 

*(  VTS  Transparent  Set  )* 


Control-objects  = 
{ 

{  *(  PAD  - 

Each  element  of  the  PAD  CO  represents  a  CCITT  PAD  parameter.  The  CO-element-id 

of  each  element  has  been  chosen  so  that  it  would  be  the  same  value  as  the  CCITT  PAD 

parameter  number  that  it  represents.  The  PAD  CO  is  used  both  to  set  CCITT  PAD 

parameter-equivalent  values  and  to  reply  to  an  update  to  the  READ  CO.  See  Definitive 

Note  25  for  conventions  concerning  updates  to  this  CO.  )* 

CO-name      =  PAD, 

CO-structure  =  22, 

co-access     =  "NSAC", 

CO-priority     =  "normal", 

CO-trigger      =  "not-selected", 

{        *(  X.3  parameter  1  -  PAD  recall  )* 

CO-element-id         =  1, 

CO-category  =  "transparent", 

CO-size  =  8  }, 

{        *(  X.3  parameter  2  -  PAD  echo  )* 

CO-element-id  =  2, 

CO-category  =  "boolean", 

co-size  =  1  }, 

{        *(  X.3  parameter  3  -  Data  Fonwarding  Character  )* 
CO-element-id  =  3, 

CO-category  =  "boolean", 

co-size  =  7  }, 
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{ 

*(  X.3  parameter  4  -- 

Idle  Timer  Delay  )* 

CO-element-id 

=  4, 

CO-category 

=  "integer", 

co-size 

=  255  }, 

{ 

*(  X.3  parameter  5  - 

Ancillary  Device  Control  )* 

CO-element-id 

=  5, 

CO-category 

=  "boolean", 

CO-size  ^ 

=  1  }. 

{ 

*(  X.3  parameter  6  - 

Control  of  PAD  Signals  )* 

CO-element-id 

=  6, 

CO-category 

=  "transparent", 

co-size 

=  4}, 

{ 

*(  X.3  parameter  7  - 

PAD  action  on  receipt  of  Break  )* 

CO-element-id 

=  7, 

CO-category 

=  "boolean", 

co-size 

=  5}, 

{ 

*(  X.3  parameter  8  ~ 

Discard  Output  )* 

CO-element-id 

=  8, 

CO-category 

=  "boolean", 

co-size 

=  1  }, 

{ 

*(  X.3  parameter  9  - 

Padding  After  <CR>  )* 

CO-element-id 

=  9, 

CO-category 

=  "integer". 

CO-size 

=  7}, 

{ 

*(  X.3  parameter  10  • 

■-  Line  Folding  )* 

CO-element-id 

=  10, 

CO-category 

=  "integer". 

CO-size 

=  255  }. 

{ 

*(  X.3  parameter  1 1  • 

■-  Device  Speed  )* 

CO-element-id 

=  11, 

CO-category 

=  "symbolic", 

CO-category 

=  19  }, 

{ 

*P<.3  parameter  12  - 

■  Flow  Control  by  Device  )* 

CO-element-id 

=  12, 

CO-category 

=  "boolean", 

CO-size 

=  1  }, 

{ 

*(  X.3  parameter  13  ■ 

--  Insert  <LF>  after  <CR>  )* 

CO-element-id 

=  13, 

CO-category 

=  "boolean", 

CO-size 

=  3}, 

{ 

*(  X.3  parameter  14 

•-  Linefeed  Padding  )* 

CO-element-id 

=  14, 

CO-category 

=  "integer". 

CO-size 

=  7}, 

{ 

*(  X.3  parameter  15  • 

--  Editing  )* 

CO-element-id 

=  15, 
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CO-category  =  "boolean", 

co-size  =  1  }, 

{        *(  X.3  parameter  16    Character  Delete  )* 

CO-element-ld  =  16, 

CO-category  =  "character", 

CO-repertoire-assignment    *(  any  from  CO  )* 

=  "void",  "void",  <ESC>  2/1  4/0, 

co-size  =  1  }, 

{        *(  X.3  parameter  17  --  Line  Delete  )* 

CO-element-ld         =  17, 

CO-category  =  "character", 

CO-repertoire-assignment  *(  any  from  CO  )* 

=  "void",  "void",  <ESC>  2/1  4/0, 

co-size  =  1  }, 

{        *{  X.3  parameter  18  --  Line  Display  )* 

CO-element-id         =  18, 

CO-category  =  "character", 

CO-repertoire-assignment  *(  any  from  CO  )* 

=  "void",  "void",  <ESC>  2/1  4/0, 

co-size  =  1  }, 

{        *(  X.3  parameter  19  --  Editing  Service  Signals  )* 

CO-element-id         =  19, 

CO-category  =  "transparent", 

CO-size  =  8  }, 

{        *(  X.3  parameter  20  -  Echo  Mask  )* 

CO-element-id         =  20, 

CO-category  =  "boolean", 

CO-size  =  8  }, 

{        *(  X.3  parameter  21  ~  Parity  Treatment  )* 

CO-element-id         =  21 , 

CO-category  =  "boolean", 

CO-size  =  2  }, 

{        *(  X.3  parameter  22  ~  Page  Wait  )* 

CO-element-id         =  22, 

CO-category  =  "integer", 

CO-size  =  256  } 


{  *(  READ  - 

Each  boolean  of  the  READ  CO  represents  an  element-id  of  the  PAD  CO  with  the  same 
identifying  value.  The  READ  CO  is  used  to  request  the  current  values  of  PAD  CO,  which 
may  have  been  changed  by  some  local  agent.  See  the  description  of  the  PAD  CO  for 
how  the  update  to  this  CO  modifies  the  access  to  the  PAD  CO.  )* 
CO-name       =  READ, 
CO-structure  =  1, 

CO-access     =  opposite  of  profile-argument-rl , 
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CO-prlority 

CO-trigger 

CO-category 

co-size 

}. 


"normal", 
"not-selected", 
"boolean". 
22 


{  *(  Break  Out-of-Band  - 

receipt  of  this  control  object  represents  "X.25  Interrupt";  use  is  applicable  when  boolean 

1  of  element-id  7  in  PAD  CO  has  the  value  "true."  )* 

co-name      =  BO, 

CO-structure  =  1, 

co-access     =  "hiSAC*, 

CO-priority     =  "urgent", 

CO-trigger      =  "not-selected", 

CO-category  =  "symbolic", 

co-size        =  i 


{  *{  Break  In-Band  - 

receipt  of  this  control  object  represents  "indication  of  break";  use  is  applicable  when 

boolean  3  of  element-id  7  in  PAD  CO  has  the  value  "true."  )* 

CO-name      =  Bl, 

CO-structure  =  1, 

co-access     =  "NSAC, 

CO-priority     =  "normal", 

CO-trigger      =  "selected", 

CO-category  =  "symbolic", 

co-size        =  I 
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{  *(  CUD  - 

This  CO  is  used  to  optionally  convey  Call  User  Data  which  is  normally  carried  in  the 
CCITT  PAD  call.  The  CO  is  not  updatable,  but  may  be  given  initial  content  value  by 
special  profile  arguments  r2  and  r3.  The  CO  is  parametric,  with  two  elements,  one 
representing  the  protocol  identifier  field,  and  the  other  representing  the  call  data  field 
containing  user  data.  )* 
CO-name       =  CUD, 
CO-structure   =  2, 
CO-access     =  "no-access", 
{        *(  Protocol  Identifier  )* 
CO-element-id  =  1, 
CO-category  =  "character", 
CO-repertoire-assignment  *(  VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
CO-size         =  4  }, 
{        *(  User  Data  )* 
CO-element-id  =  2, 
CO-category  =  "character", 
CO-repertoire-assignment  *(\/TS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 
co-Size  =  124  } 

}. 

{  *(  DTE  - 

This  CO  is  used  to  optionally  indicate  the  calling  and  called  DTE  addresses  which  are 

normally  available  in  a  true  CCITT  PAD  environment.  They  may  not  be  updated,  but  may 

be  given  initial  content  values  by  special  profile  arguments  r4  and  r5.  )* 

CO-name       =  DTE, 

CO-structure  =  2, 

CO-access     =  "no-access", 

{        *(  Calling  DTE  address  )* 

CO-element-id  =  1, 

CO-category  =  "character", 

CO-repertoire-assignment  *(\/TS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 

co-size  =  15  }, 

{        *(  Called  DTE  address  )* 

CO-element-id  =  2, 

CO-category  =  "character", 

CO-repertoire-assignment  *(VTS  Transparent  Set  )* 

=  <ESC>  2/5  2/15  4/2, 

co-size  =  15  } 

}. 
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Table  13  -  PAD  CO  data  element  1  value  definition 


value 

■eeining 

0 

not-permitted 

1 

1/0  character  (DLE) 

32-126 

graphic  character 

^2.  '  The  value  assigned  to  element  2  of  PAD  CO  determines  whether  or  not  characters  are  echoed  at 
the  terminal-system.  When  the  value  of  this  boolean  is  "true,"  then  the  characters  are  echoed  at  tlie 
terminal-system. 

3.  The  values  assigned  to  element  3  of  PAD  CO  control  the  forwarding  of  characters  from  the  terminal- 
^  system  to  the  application-system  based  on  the  character  value.  The  defined  booleans  and 
■         associated  meanings  are: 

Table  14  -  PAD  CO  data  element  3  value  definition 


boolecin 

meaning 

1 

alphanumeric  (A-Z,  a-z,  0-9) 

2 

character  0/13  (CR) 

3 

characters  1/11  (ESC),  0/7  (BEL), 
0/5   (ENQ),   0/6  (ACK) 

4 

characters  7/15  (DEL),  1/8  (CAN), 
1/2  (DC2) 

5 

characters  0/3  (ETX),  0/4  (EOT), 

6 

characters  0/9  (HT),  0/10  (LF), 
0/11   (VT),   0/12  (FF) 

7 

all  others  in  column  0  and  1  not 
already  included  above 

4.  The  value  assigned  to  element  4  of  PAD  CO  controls  the  forwarding  of  characters  from  the  terminal- 
system  to  the  application-system  based  on  the  duration  of  idle  time  elapsed  between  consecutive 
characters  received  by  the  terminal-system  from  the  device.  The  valid  values  include  any  non- 

^  negative  integer  0-255;  a  value  between  1  and  255  indicates  the  time-out  in  twentieths  of  a  second; 
a  value  of  0  means  that  a  time-out  is  not  a  forwarding  condition. 

5.  The  value  assigned  to  element  5  of  PAD  CO  determines  whether  the  XON/XOFF  flow-control 
characters  (1  /1  and  1  /3)  are  available  for  use  by  the  terminal-system.  When  the  value  of  this 
element  is  "true,"  then  the  flow-control  characters  are  available,  and  the  terminal-system  may  use 
them  to  indicate  to  the  device  its  readiness  to  accept  characters  from  it. 

6.  The  value  assigned  to  element  6  of  PAD  CO  determines  whether  the  terminal-system  issues 
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messages,  called  PAD  service  signals,  to  the  device  during  the  association.  The  specific  service 
signals  are  not  a  part  of  this  profile  definition,  only  the  control  of  their  issue. 

The  values  assigned  to  element  7  of  PAD  CO  determine  the  behavior  at  the  terminal-system  when 
a  Break  is  received  from  the  device.  The  defined  bodeans  and  associated  meanings  are: 

Table  15  -  PAD  CO  data  element  7  value  definition 


boolesm 

■eaning 

1 

update  BO  CO 

2 

release  the  association 

3 

update  BI  CO 

4 

return  control  to  terminal-system 

5 

discard  data  from  application-system 

When  all  booleans  have  the  value  "false,"  there  is  no  action  at  the  terminal-system  when  a  Break  is 
received. 


When  bocftean  i  Is  true"  aiKl  bodeans  0  and  are  "1^^  mi  a  Bveak  is  rece^  from  thede^, 
IH$  I9miln$l'^^l$m  Upd^^     BO  CO  t«^ith  1^9  $v^bQllo  v^iu^  '^ot^.* 


V^en  booleans  1  and  3 

if  ue*  md  booleari  8   "false**  and  a  Break  Is  re<5^ed  i«m 

the  device. 

the  lenn&iai 

system  updates  the 

80  CO  wl^  ^e  ^y?TJb<^fe  value  "prepare' 

Mamd  by 

m  updlaie  Ie>  Ihe  BI  CO  ^  ^  ^pibo^c  valtie  "uncot^ttrnd.* 

When  boolear»  1, 5^  arid  5  are  all  irt^*  and  a  Break  Is  recelvsd  irom  Hie  device,  the 
bmirir^  ^f^^  tipdales  t®^  iO  00  wini  tie  symbolic  vaJue  "prepare*  ic^iowed  fe^  arj 
tipdal%l&  the  BI  CD  with  tNe  eymbdlc;  "oottlirmed"  d^ciards  d'^play  ob|e(^ 
updates  from  Uie  aj^icatlof>  ^^imn  urm  it  receives  an  update  to  the  PAD  CO  selecting 
ei^nehi-ld 


ff  faode^ai  1  is  iaise,''  then  boc^e^s  3  and  5  must  be  *false.* 
)l  bo^e^  3  Is  '"false,*  then  bo(^e£^  5  must  be  *false«* 


Table  16  -  ^  CO  vii]tte«  and  semaratcs 


ajicouliirwe^ 

1)1 

i 
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T^bl^  17  ^  BO  CO  V9i|i«il  imni  s^mantlos 


iiiii 

i 

A  uooful  combination  of  booloano  with  valuo  "truo"  io  (1,3,6).  Whon  a  Broak  ic  roooivod, 
the  terminal  oyotom  updatoo  botli  tho  BO  CO  and  the  Bl  CO  and  diooardo  all  dioplay 
object  updatoG  from  the  application  oyctom  until  It  roooivoo  an  update  to  the  PAD  CO  for 
element  8.  The  result  is  that  the  data  path  hao  been  cleared  In  both  directions.  Notice 
that  this  ic  non  destructive  of  control  object  updates. 

8.  The  value  assigned  to  element  8  of  PAD  CO  determines  whether  or  not  the  terminal-system  discards 
data  from  the  application-system.  This  element  works  with  element  7  to  acknowledge  the  receipt 
of  the  Break  and  resume  normal  processing  of  display-object  updates.  The  only  valid  value  of  this 
boolean  in  an  update  is  "false." 

9.  The  value  assigned  to  element  9  of  PAD  CO  indicates  the  number  of  padding  characters  to  be 
generated  by  the  terminal-system  to  the  device  following  a  carriage  return  character.  The  valid 
values  are  integers  in  the  range  0-7. 

10.  The  value  assigned  to  element  10  of  PAD  CO  indicates  the  number  of  graphic  characters  sent  to 
the  device  after  which  the  terminal-system  will  insert  a  carriage  return.  The  valid  values  are  integers 
In  the  range  0-255,  where  a  value  of  0  means  that  this  function  is  not  performed. 

1 1 .  The  value  assigned  to  element  1 1  of  PAD  CO  indicates  the  bit-transmission  speed  of  the  device. 
This  element  may  only  appear  in  an  update  sent  to  the  application-system  in  response  to  an  update 
of  the  READ  CO  when  boolean  1 1  has  the  value  "true." 

12.  The  value  assigned  to  element  12  of  PAD  CO  determines  whether  the  XON/XOFF  flow-control 
characters  (1/1  and  1/3)  are  available  for  use  by  the  device.  When  the  value  of  this  element  is 
"true,"  then  the  flow-control  characters  are  available,  and  the  device  may  use  them  to  indicate  to  the 
terminal-system  its  readiness  to  accept  characters  from  it. 

13.  The  values  assigned  to  element  13  of  PAD  CO  determine  under  which  situations  a  linefeed  is 
Inserted  following  a  carriage  return  character.  The  valid  values  and  associated  meanings  are: 
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Table  18  -  PAD  CO  data  element  13  value  definition 


boolean 

■eaning 

1 

insert  linefeed  after  carriage 
return  sent  to  device 

2 

insert  linefeed  after  carriage 
return  received  from  device 

3 

insert  linefeed  after  carriage 
return  echoed  to  the  device 

14.  The  values  assigned  to  element  14  of  PAD  CO  determine  the  number  of  padding  characters 
generated  by  the  terminal-system  to  the  device  following  a  linefeed  character.  The  valid  values  are 
any  number  in  the  range  0-7. 

15.  The  value  assigned  to  element  15  of  PAD  CO  determines  whether  or  not  the  terminal-system 
performs  data-editing.  When  this  CO  has  value  "true,"  the  values  of  the  elements  3  and  4  of  the 
PAD  CO  are  ignored. 

16.  The  value  assigned  to  element  16  of  PAD  CO  determines  which  character  is  used  in  editing  the  line 
to  signify  the  function  "delete  character."  The  valid  values  are  the  IA5  characters,  decimal  value  0- 
127.  Only  applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

17.  The  value  assigned  to  element  17  of  PAD  CO  determines  which  character  is  used  in  editing  to 
signify  the  function  "delete  line."  The  valid  values  are  the  IA5  characters,  decimal  value  0-127.  Only 
applicable  if  the  value  of  element  15  of  PAD  CO  Is  "true." 

18.  The  value  assigned  to  element  18  of  PAD  CO  determines  which  character  is  used  in  editing  to 
signify  the  function  "display  line."  The  valid  values  are  the  IA5  characters,  decimal  value  0-127.  Only 
applicable  if  the  value  of  element  15  of  PAD  CO  is  "true." 

19.  The  value  assigned  to  element  19  of  PAD  CO  determines  whether  the  terminal-system  provides  for 
editing  of  PAD  sen/ice  signals.  The  valid  values  and  meanings  are  as  follows: 
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Table  19  -  PAD  CO  data  element  19  value  definitions 


value 

meeming 

0 

no  editing 

1 

editing  as  £or  a  paper  device 

2 

editing  as  for  a  glass  device 

8 

editing  using  one  editing  character 

32-126 

editing  using  one  editing  character 

20.  The  values  assigned  to  element  20  of  PAD  CO  determines  whiich  characters  are  NOT  to  be  echoed 
to  the  device  by  the  terminal-system.  If  no  bits  are  set,  then  all  characters  are  to  be  echoed, 
assuming  that  element  2  has  the  value  "true."  The  defined  booleans  and  associated  meanings  are: 


Table  20  -  PAD  CO  data  element  20  value  definition 


boolean 

meaning 

1 

Do  not  echo  0/13  (CR) 

2 

Do  not  echo  0/10  (LF) 

3 

Do  not  echo  0/11  (VT),   0/9   (HT),   0/12  (FF) 

4 

Do  not  echo  0/7  (BEL),  0/8  (BS) 

5 

Do  not  echo  1/11  (ESC),  0/5  (ENQ) 

6 

Do  not  echo  0/6   (ACK),   1/5   (NAK),   0/2  (STX), 
0/1  (SOH),   0/4   (EOT),   1/7   (ETB) ,   0/3  (ETX) 

7 

Do  not  echo  the  editing  characters  defined  by 
data  elements  16,  17,  and  18  of  the  PAD  CO 

8 

Do  not  echo  7/15  (DEL)  or  any  of  the  other 
characters  belonging  to  CO  or  CI  which  are 
not  already  mentioned  above 

21.  The  value  assigned  to  element  21  of  PAD  CO  determines  the  treatment  of  parity  on  the  characters 
received  from  and  sent  to  the  device  from  the  terminal-system.  The  defined  booleans  and 
associated  meanings  are: 
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Table  21  -  PAD  CO  data  element  21  value  definition 


boolean 

meaning 

1 

parity  is  checked  on  characters 
received  from  the  device 

2 

parity  is  generated  on  characters 
sent  to  the  device 

22.  The  value  assigned  to  element  22  of  PAD  CO  determines  the  number  of  linefeeds  that  the  terminal- 
system  may  send  to  the  device  before  it  must  wait  for  input  from  the  device  to  request  it  to  continue 
displaying  characters.  The  range  of  valid  values  is  0-255,  where  a  value  of  0  indicates  that  the 
terminal-system  need  never  wait. 

23.  The  TEXT  operation  is  the  only  operation  allowed  on  the  display  objects. 

24.  Special  profile  arguments  r2-r6  have  binary  values.  However,  due  to  a  restriction  in  the  standards 
9040  and  9041,  those  binary  values  must  be  conveyed  in  the  ASN.1  type  PrintableString.  This  is 
accomplished  by  mapping  the  value  of  each  semi-octet  in  the  string  of  binary  octets  to  an  octet 
whose  value  falls  in  the  value  range  of  a  PrintableString.  The  semi-octet  values  in  the  range  0000  - 
1001  are  mapped  into  the  PrintableString  values  '0'  -  '9',  whereas  the  semi-octet  values  in  the  range 
1010  - 1 1 1 1  are  mapped  into  the  PrintableString  values  'A'  -  'F'.  The  result  is  a  string  of  characters 
which  is  exactly  twice  the  length  of  the  original  string  of  binary  octets. 

25.  The  value  of  CO-access  for  the  PAD  CO  is  "NSAC,"  however  a  convention  is  followed  that 
determines  when  a  VT-user  may  update  the  PAD  CO.  Only  the  VT-user  with  access  to  the  Display 
Object  D2  may  update  the  PAD  CO  except  immediately  after  it  has  updated  the  READ  CO.  When 

'  the  READ  CO  update  is  received  by  the  opposite  VT-user,  it  is  treated  as  a  request  to  update  the 
PAD  CO  with  the  parameter  values  it  is  currently  using,  at  which  point  that  VT-user  is  required  to 
respond. 

The  applteato  system:  can  update  the  B}  CO  and  tbe  terminal  syslem  shall  swid  a  Bmsk  to  t$\e 
etevicie.  a  th$  symbolic  valiie  of  the  updM&  ''ODhflf med/  the  ter mlnsl  system  shall  resp&nd  with 
m  updi^e  to  the  PAD  CO  selecting  elemcRt-jd  0* 


8.4.5.2        Informative  Notes 

1.  Users  of  this  profile  should  refer  to  CCITT  Recommendations  X.3,  X.28  and  X.29  for  the  original 
model  for  this  profile. 

2.  The  following  values  for  the  elements  of  the  PAD  CO  are  taken  from  the  CCITT  Simple  standard 
profile  and  may  prove  useful: 
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 Table  20  -  CCITT  Simple  Standard  profile 


data  element 

value 

1 

1 

possible  to  return  control  to 
terminal-system  using  0/1  (DLE) 

2 

1. "true" 

echo  performed  at  the  terminal-system 

3 

1.  "false", 

2.  "true",  3. "true", 
4. "true",  5. "true", 
6. "true",  7. "true" 

forward  on  receipt  of  any  character  in 
CO  and  CI 

4 

 '  

0 

no  time-out  used  for  forwarding 
condition 

5 

1. "true" 

terminal-system  may  use  XON/XOFF  to 
flow-control  the  device 

6 

1. "true" 

service  signals  are  sent 

7 

2. "true",  all 
others  "false" 

release  the  association  when  a  Break 
is  received  from  the  device 

8 

1. "false" 

deliver  data  to  device 

9 

0 

do  not  pad  after  CR 

10 

0 

do  not  fold  the  line 

11 

read-only 

12 

1. "true" 

device  may  use  XON/XOFF  to  flow- 
control  the  terminal-system 

13 

0 

do  not  insert  LF  after  CR 

14 

0 

do  not  pad  after  LF 

15 

1. "false" 

do  not  edit  data 

16 

7/15  (DEL) 

character  delete 

17 

1/8  (CAN) 

line  delete 

18 

1/2  (DC2) 

line  display 

19 

1 

edit  as  for  paper 

20 

0 

echo  all  characters 

21 

0 

no  parity  checking  or  generation 

22 

0 

no  page  wait 

'<  3.  The  following  values  for  the  elements  of  the  PAD  CO  are  taken  from  the  CCITT  Transparent  standard 
1  profile  and  may  prove  useful. 
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Table  21  -  CCITT  Transparent  Standard  profile 


data  element 

value 

meaning 

1 

0 

control  may  not  be  returned  to  the 
terminal-system 

2 

1 . "false" 

terminal— system  does  not  perform 
character  echo 

1 

3 

all  booleans 
"false" 

no  forwarding  on  character  value 

f 

4 

20 

forward  on  time-out  of  1  second 

ij 

5 

1. "false" 

terminal-system  may  not  flow-control 
une  aevice 

c 
o 

X,  taise 

service  signaxs  are  never  senu 

i| 

ij  ■ 

1 

O      ll4-v-«Y^II  ^11 

z .  true  f  aii 
others  "false" 

release  the  association  when  a  Break 
is  received  from  the  device 

o 
O 

1   II  p  ia  1  ^  II 
1 .  raise 

deliver  data  to  device 

Q 

u 

uo  noT.  pau  axrer  v^k 

1  n 

n 

Qo  iioc  x\jxQ  Liie  X X lie 

i>-  - 

1  1 

1  7 
J. 

1     II  fa  1  CO  1' 
X •     X  a  X  a6 

cieviC'e  may  1101^   xxv^w— ov/iiur^c^x  uiie 
terminal-system 

13 

0 

do  not  insert  LF  after  CR 

i' 

14 

0 

do  not  pad  after  LF 

.( 

15 

1. "false" 

do  not  edit  data 

;> 

16 

7/15  (DEL) 

character  delete 

17 

1/8  (CAN) 

line  delete 

18 

1/2  (DC2) 

line  display 

it 

19 

1 

edit  as  for  paper 

20 

0 

echo  all  characters 

21 

0 

no  parity  checking  or  generation 

22 

0 

no  page  wait 
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Decembenggi  (Stable) 


None. 


8.5      Generalized  Telnet  Profile 

OIW  VTE-Profile  Generalized  Telnet-1991  (r1,r2) 


8.5.1  Introduction 

This  profile  provides  support  for  TELNET-like  operation  for  users  of  the  ISO  Virtual  Terminal  Service.  It  is 
based  on  the  IS  version  of  ISO  9040  and  ISO  9041.  This  profile  references  the  ARPA  Internet  TELNET 
standards  documents  for  the  semantics  of  option  negotiation  and  the  values  of  symbolic  constants. 


8.5.2       Association  Requirements 


8.5.2.1         Functional  Units 

The  Structured  Control  Objects  Functional  Unit  is  required.  The  Urgent  Data  Functional  Unit  is  optional,  but 
should  be  used  whenever  available. 


8.5.2.2  Mode 

This  is  an  A-mode  profile. 


8.5.3       Profile  Body 

Display-objects  =  *  (double  occurrence)* 
{ 

{ 

display-object-name  =  D,  *(DISPLAY)* 

do-access  =  "WACA", 

dimensions  =  "two", 

x-dimension  = 

{ 

x-bound  =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute  =  "yes",        *(See  Definitive  Note  5)* 

x-window  =  profile-argument-r1 
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y-dimension  = 
{ 

y-bound        =  "unbounded", 
y-addressing  =  "higher  only", 
y-absolute      =  "no", 
y-window       =  1 

}, 

erasure-capability      =  "yes", 
repertoire-capability   =  *(implicitly  defined  by  r2)*, 
repertoire-assignment         =  profile-argument-r2, 
repertoire-assignment         =  <  ESC  >  2/5  2/15  4/2 
}. 
{ 

display-object-name  =  K,  *(KEYBOARD)* 
do-access  =  "WACI", 

dimensions  =  "two", 

x-dimension  = 

{ 

x-bound  =  "unbounded", 

x-addressing  =  "no  constraint", 

x-absolute  =  "yes",        *(See  Definitive  Note  5)* 

x-window  =  profile-argument-r1 

y-dimension  = 
{ 

y-bound        =  "unbounded", 
y-addressing  =  "higher  only", 
y-absolute      =  "no", 
y-window       =  1 

}, 

erasure-capability      =  "yes", 
repertoire-capability    =  *(implicitly  defined  by  r2)*, 
repertoire-assignment         =  profile-argument-r2, 
repertoire-assignment         =  <  ESC  >  2/5  2/15  4/2 
}. 

}. 

Control-objects  =  *  (multiple  occurrence)* 
{ 

{  *(SYNCHRONIZE)* 

co-name       =  SY, 
CO-category  =  "symbolic", 
co-access     =  "NSAC", 
co-size         =  1, 
CO-priority     =  "urgent" 

}, 
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{  *(DISPLAY-SIGNAL)* 

co-name       =  Dl, 
CO-category  =  "symbolic", 
co-size         =  255, 
co-access     =  "WACA", 
CO-priority     =  "normal", 
co-trigger      =  "selected" 

}. 

{  *(KEYBOARD-SIGNAL)* 
co-name       =  KB, 
CO-category  =  "symbolic", 
co-size         =  255, 
co-access     =  "WACI", 
CO-priority     =  "normal", 
CO-trigger      =  "selected" 

}. 

{  *{NEGOTIATION  BY  INITIATOR)* 
co-name       =  Nl, 
CO-structure    =  2, 
*(DO/DONT)* 
CO-element-id    =  1, 
CO-category     =  "boolean", 
co-size         =  256, 
*{WILL/WONT)* 
CO-element-id   =  2, 
CO-category     =  "boolean", 
co-size         =  256, 
co-access     =  "WACI", 
CO-priority     =  "normal", 
CO-trigger      =  "selected" 

}. 

{  *(NEGOTIATION  BY  ACCEPTOR)* 
CO-name       =  NA, 
CO-structure    =  2, 
*(DO/DONT^* 
CO-element-id   =  1, 
CO-category     =  "boolean", 
co-size        =  256, 
*  (WILL/WONT)* 
CO-element-id    =  2, 
CO-category     =  "boolean", 
co-size         =  256, 
co-access     =  "WACA", 
CO-priority     =  "normal", 
CO-trigger      =  "selected" 
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{  *(SUBNEGOTIATION  BY  INITIATOR)* 
CO-name       =  SBI, 
CO-structure    =  2, 

*{TELNET  OPTION)* 

CO-element-id   =  1, 

CO-category     =  "symbolic", 

CO-size         =  256, 

*(SUBNEGOTIATION)* 

CO-element-id   =  2, 

CO-category     =  "character", 

CO-repertoire-assignment  =  <  ESC  >  2/5  2/15  4/2, 

*{\/irtual  Terminal  Service  Transparent  Set)* 

co-size         =  1024, 
co-access     =  "WACI", 
CO-priority     =  "normal", 
CO-trigger      =  "selected" 

}, 

{  *(SUBNEGOTIATION  BY  ACCEPTOR)* 
CO-name       =  SBA, 
CO-structure    =  2, 

♦(TELNET  OPTION)* 

CO-element-id   =  1, 

CO-category     =  "symbolic", 

co-size         =  256, 

*(SUBNEGOTIATION)* 

CO-element-id   =  2, 

CO-category     =  "character", 

CO-repertoire-assignment  =<  ESC  >  2/5  2/15  4/2, 

*(Virtual  Terminal  Service  Transparent  Set)* 

CO-size         =  1024, 
co-access     =  "WACA", 
CO-priority     =  "normal", 
CO-trigger      =  "selected" 

}. 

Device-objects  =  *{double  occurrence)* 
{ 

{ 

device-name  =  DISPLAY-DEVICE, 

device-display-object  =  D, 

device-default-CO-initial-value         =  1."true",*{on)* 
device-minimum-X-array-length       =  1,*(no  constraint) 
device-minimum-Y-array-length       =  1,* (no  constraint) 
device-control-object  =  SY, 
device-control-object  =  NA, 
device-control-object  =  Dl, 


* 
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device-control-object  =  SBA, 

*(SYNC,  NEGOTIATE-ACCEPTOR, 
DISPLAY-SIGNAL,  SUBNEGOTIATE-ACCEPTOR)* 

device-default-CO-access     =  "WACA", 

device-default-CO-priority     =  "normal" 

*  (other  device  object  parameters  assume  corresponding 

DO  values)* 

}. 
{ 

device-name  =  KEYBOARD-DEVICE, 

device-display-object  =  K, 

device-default-CO-initial-value         =  1."true",*(on)* 
device-minimum-X-array-length       =  1,*(no  constraint)* 
device-minimum-Y-array-length       =  1  ,*(no  constraint)* 
device-control-object  =  SY, 
device-control-object  =  Nl, 
device-control-object  =  KB, 
device-control-object  =  SBI, 

*(SYNC,  NEGOTIATE-INITIATOR, 

KEYBOARD-SIGNAL,  SUBNEGOTIATE-INITIATOR)* 
device-default-CO-access     =  "WACI", 
device-default-CO-priority     =  "normal" 
*(other  device  object  parameters  assume  corresponding 
DO  values)* 
} 

Type  of  delivery  control  =  "simple-delivery-control." 


8.5.4       Profile  Argument  Definitions 

r1  -  is  used  to  represent  the  line  length  as  the  value  of  VTE  parameter  x-window  for  both  display 
objects.  This  argument  is  mandatory  and  takes  a  nonnegative  integer  value.  This  argument  is 
identified  by  the  identifier  for  x-window  for  display  object  D. 

r2  -  is  used  to  designate  the  repertoires  for  both  display  objects.  This  argument  is  optional,  and  may 
occur  a  number  of  times  in  an  ordered  list  to  provide  for  negotiation  of  values  for  the  VTE-parameter 
repertoire-assignment.  The  value  for  the  VTE-parameter  repertoire-capability  is  implied  by  the 
number  of  occurrences  of  this  profile  argument.  The  VTE-parameter  repertoire-capability  equals  the 
number  of  occurrences  of  this  profile  argument  plus  one.  The  default  is  a  single  occurrence  of  the 
value  designating  the  full  US  ASCII  set.  This  argument  is  identified  by  the  identifier  for  repertoire 
assignment  for  display  object  D. 
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8.5.5       Profile  Dependent  CO  Information 


8.5.6       Profile  Notes 


8.5.6.1         Definitive  Notes 


1.  Sending  a  KB  or  DI  control  object  update  is  the  equivalent  of  sending  a  TELNET  "lAC 
<  comnnand  > "  sequence.  The  synnbolic  value  in  the  KB  or  DI  control  object  update  is  equal 
to  the  TELNET  command  code  as  specified  in  the  TELNET  Assigned  Numbers. 

The  following  values  must  be  recognized: 


SYMBOLIC 

NAME 

VALUE 

DM 

Data  Mark 

242 

BRK 

Break 

243 

IP 

Interrupt  Process 

244 

AO 

Abort  output 

245 

AYT 

Are  You  There 

GA 

Go  ahead 

249 

The  following  values,  corresponding  to  TELNET  commands,  are  excluded  from  KB  and  DI 
control  object  updates: 


SYMBOLIC 

NAME 

VALUE 

SE 

End  Subnegotiation 

240 

EC 

Erase  character 

247 

EL 

Erase  Line 

248 

SB 

Subnegotiation 

250 

WILL 

Will 

251 

WONT 

Won't 

252 

DO 

Do 

253 

DONT 

Don't 

254 

lAC 

Escaped  lAC 

255 

The  Nl  and  NA  control  objects  are  used  in  place  of  the  DO,  DONT,  WILL,  WONT 
commands. 

The  SBI  and  SBA  control  objects  are  used  in  place  of  the  SB  <suboptions>  SE 
command  sequence. 

The  EC  and  EL  commands  are  replaced  by  display  object  updates. 
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The  lAC  is  not  needed  because  commands  are  not  embedded  in  the  text. 

The  recognition  of  values  corresponding  to  TELNET  commands  defined  in  a  TELNET 
option  will  be  dependent  upon  the  successful  negotiation  of  the  TELNET  option  that  defines 
the  additional  TELNET  command.  Unrecognized  values  shall  be  ignored. 

2.  The  equivalent  of  a  TELNET  SYNCH  command  is  achieved  by  updating  the  SY  control 
object  with  the  single  symbolic  value  of  "SYNCH"  (which  is  mapped  onto  the  integer  value 
1),  and  immediately  updating  the  Dl  (or  KB)  control  object  with  symbolic  value  DM.  When 
an  update  to  the  SY  control  object  is  received  subsequent  display  object  updates  are 
discarded  until  an  update  to  the  Dl  or  KB  control  is  received  with  symbolic  value  DM.  If  a 
VT-BREAK  is  received  after  an  SY  CO  update  has  been  received  and  prior  to  the 
corresponding  Dl  or  KB  CO  update  with  symbolic  value  of  DM,  the  discarding  of  updates 
Is  terminated.  This  is  necessary  because  the  VT-BREAK  may  have  caused  the  Dl  or  KB  CO 
update  to  be  purged. 

3.  The  Nl  and  NA  control  objects  are  used  to  emulate  the  TELNET  option  negotiation  facility. 
The  facility  is  symmetric,  allowing  either  party  to  open  negotiation  for  a  change  of  mode, 
and  every  negotiation  must  be  accepted  or  rejected  by  the  opposite  party.  The  rules  for 
negotiation  for  each  of  the  option  controls  are  as  stated  in  the  TELNET  specification  and 
as  given  below: 

a.  Only  open  negotiation  for  a  change  from  the  current  state; 

b.  Only  acknowledge  negotiation  for  a  change  from  the  current  state; 

c.  Do  not  send  any  object  updates  with  a  negotiation  outstanding  except  an 
update  to  the  Nl  (or  NA)  control  object  to  acknowledge  negotiation. 

Nl  and  NA  are  structured  control  objects  consisting  of  two  boolean  data  elements.  For  full 
symmetry,  both  Nl  and  NA  have  the  same  value  definitions.  The  first  boolean  data  element 
stands  for  DO/DONT  and  the  second  boolean  data  element  stands  for  WILL/WONT.  The 
ordinal  position  of  the  boolean  value  in  the  data  element  corresponds  to  the  TELN  ET  option 
number  plus  one.  This  allows  the  ordinal  position  of  bits  1-256  in  the  boolean  object  to 
represent  the  TELNET  options  values  of  0-255.  DO  is  represented  as  a  "true"  boolean  value 
in  CO-element-id  1 .  DONT  is  represented  as  a  "false"  boolean  value  in  CO-element-id  1 . 
WILL  is  represented  as  a  "true"  boolean  value  in  CO-element-id  2.  WONT  is  represented 
as  a  "false"  boolean  value  in  CO-element-id  2. 

4.  The  SBI  and  SBA  control  objects  provide  subnegotiation  for  TELNET  options,  and 
correspond  to  the  TELNET  command  sequence  "lAC  SB  <TELNET  option  code> 
< subnegotiation  >  lAC  SE".  Element  id  1  contains  the  TELNET  option  code,  and  element 
id  2  contains  the  octets  that  comprise  the  subnegotiation.  The  specification  for  the  TELNET 
option  defines  the  semantics  of  the  value  in  element  id  2. 

5.  The  TELNET  EC  (erase  character)  command  will  be  mapped  to  a  pointer  relative  (x:  =  x-1 ) 
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update  and  an  erase  current  update.  This  is  the  only  instance  when  backward  explicit 
addressing  is  permitted. 

The  TELNET  EL  (erase  line)  command  will  be  mapped  to  an  erase-full-x-array  update  (an  erase 
operation  where  the  extent  is  defined  as  <"start-x,"Yc,Xc-1)  >  and  a  pointerupdate  to  set  x  =  1 .  This 
is  the  only  instance  when  absolute  explicit  addressing  is  permitted. 

6.  The  X  address  of  the  pointer  can  be  moved  fonA^ard  only  by  implicit  pointer  addressing. 
Addressing  of  the  Y  dimension  is  limited  to  the  next  X-array  update  operation. 

7.  The  VT  next  X-array  update  operation  will  be  sent  in  place  of  the  TELNET  NVT  "CR,  LF" 
sequence. 

8.  When  a  p^wty  want$  to  change  a  repertoire  assignment,  It  must  complete  a  euccessfwl 
TB^NET  option  mg03L^on  change  th^  repenolre  \n  use.  Th^n  ihe  paky  ^eaco^s^ 
ri^t$  IQ  Vtm  clisplay  ol;:|e<^  in  ques^on  ^  required  lo  'mm  acarresponding  update  lo  the 
modal  valine  for  Hie  dn^a&at^M^pemk^  oMbM.  If  a  negotiation  to  change  repertoire  Is 
reused,  the  client  repertoire     remain  In  effect 

U«e  of  tie  Trar^perent  character  set  for  a  cBsplay  object  is  similarly  effected  by  a  modai 
attrt)i(ie  update  fc^Mng  successful  negotiation  of  the  TELNET  Binary  Option.  When  a 
riegottatlontoiip^it  uslngthe  "binafy"  repertoire  swcceeds.  It  is  to  be  treated  as  a  negotiation 
tousetherepert<^reepedfied  by  thefirstvalueof  the  repertoire-assignment  WE-paramet^. 

Use  of  the  Tranoparont  oharaotor  sot  for  the  D  and  K  dioplay  objooto  is  controlled  by  the 
negotiation  of  the  TELNET  Binary  Option.  When  a  party  wants  to  change  a  roportoiro 
aooignmont,  it  muot  oomploto  a  suoooooful  TELNET  negotiation  to  change  the  option 
control.  Then  the  party  with  the  aooooo  rights  to  the  display  objoot  in  quootion  io  required 
to  perform  the  oorrooponding  secondary  attribute  modal  update.  If  a  negotiation  to  change 
to  "binary"  roportoiro  io  rofuood,  the  current  roportoiro  will  remain  in  effect.  When  a 
nogotiation  to  quit  using  the  "binary"  roportoiro  suoooodo,  the  party  with  the  accoso  righto 
to  the  dioplay  objoot  in  quootion  io  roquirod  to  perform  tho  corresponding  secondary 
attribute  modal  update  to  owitoh  to  the  roportoiro  dooignatod  by  the  firot  roportoiro 
aooignmont  parameter. 

9.  While  the  "binary"  repertoire  is  being  used  no  mapping  to  the  pointer  addressing  or  erase 
operations  will  be  done. 

10.  The  repertoire  designation  "7-bit  ASCII  (GO+CO)"  refers  to  the  repertoire  invoked  by  ISO 
2022  defined  character  set  designating  escape  sequences  <ESC>  2/8  4/2,  "void," 
<  ESC>  2/1  4/0.  The  repertoire  designation  "7-bit  ASCII  (GO  only)"  refers  to  the  repertoire 
invoked  by  ISO  2022  defined  character  set  designating  escape  sequences  <ESC>  2/8 
4/2.  The  designation  "binary"  refers  to  the  "Virtual  Terminal  Service  Transparent  Set" 
registered  in  the  International  Register  under  ISO  2375  register  value  125  and  invoked  by 
the  escape  sequence  <  ESC  >  2/5  2/ 1 5  4/2. 
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11.  No  termination  event  list  is  specified  so  that  data  buffering  and  delivery  can  be  controlled 
according  to  context.  If  local  echoing  is  enabled,  the  local  newline  or  other  event  shall 
trigger  a  VT-DELIVER  request.  With  rennote  echo  a  timeout  or  buffer  length  may  be  used 
to  trigger  a  VT-DELIVER  request.  This  buffer  length  may  be  1 . 

8.5.6.2        Informative  Notes 

1 .  Users  of  this  profile  should  refer  to  the  TELNET  specification  (MIL-STD-1 782)  and  RFCs: 

854  Protocol  Specification 

855  Options  Specification 

or  their  successors  for  semantics  of  the  TELNET  commands.  These  documents  can  be 
obtained  by  contacting  SRI  International,  DDN  Network  Information  Center,  333 
Ravenswood  Ave.,  MenIo  Park,  CA  94025,  (415)  859-3695. 

2.  This  profile  is  derived  from  the  Telnet-1 988  profile.  The  negotiation  control  objects,  NA  and 
Nl,  have  been  changed  to  model  the  DO/DONT  WILL/WONT  negotiation  of  TELNET 
options.  The  size  of  the  elements  of  the  NA  and  Nl  negotiation  control  objects  equals  the 
range  of  TELNET  option  numbers,  including  the  numbers  presently  assigned  and  those 
reserved  for  future  options.  An  implementation  can  refuse  options  that  it  doesn't  support. 
This  allows  implementations  to  maintain  interoperability  while  new  TELNET  options  are 
incorporated.  The  CO-category  of  the  KB  and  Dl  control  objects  have  been  changed  from 
"boolean"  to  "symbolic."  A  "Go-Ahead"  will  be  signaled  by  a  control  object  update  to  the 
Dl  or  KB  control  object  with  symbolic  value  of  GA;  therefore,  the  GA  control  object  has  been 
dropped. 

3.  If  the  "go  ahead"  facility  has  been  negotiated  then  following  a  VT-BREAK,  only  the 
association  acceptor  has  the  right  to  send  data.  In  the  event  of  VT-BREAK  the  echo  control 
objects  are  reinitialized  to  "false,"  meaning  local  echo.  If  remote  echo  is  desired  it  must  be 
re-negotiated  following  VT-BREAK. 

8.5.7       Specific  Conformance  Requirements 

The  following  character  sets  are  required: 

The  GO  character  set  for  U.S.  ASCII  (values  32-126); 
The  full  U.S.  7-bit  ASCII  (values  0-127); 

The  transparent  character  set,  see  Definitive  Note  8  in  section  1 4.8.5.6.1 . 
Hegotlato  to  ^pii^iessi  GoAh^d  must  be  i^ccept^. 
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Annex  A  (normative) 
Specific  ASE  Requirements 

For  specific  ASE  Requirements  identified  by  the  Upper  l_ayer  SIG  for  Virtual  Terminals,  see  Stable 
Implementation  Agreements  for  Open  Systems  Interconnection  Protocols:  Part  5  -  Upper  Layers. 


80 


PART  14  -  VIRTUAL  TERMINAL  December  1991  (Stable) 


Annex  B  (normative) 


Clarifications 

Defaults 

When  a  profile  argument  is  not  present  in  either  the  offer  or  value  list,  the  default  for  the  corresponding  VTE 
parameter  is  specified  by  ISO  9040  If  it  is  not  given  by  the  argument  description  in  the  profile. 


lil 
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Annex  C  (normative) 
Object  Identifiers 

General  identifiers: 

oiw-vt  OBJECTIDENTIFIER::  = 

{  iso(1)  identified-organization(3)  oiw{14)  vtsig(12)  } 

oiw-vt-pr  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt  vteProfile(l)  } 

oiw-vt-co  OBJECT  IDENTIFIER  ::  = 

{ oiw-vt  controlObject(0)  } 

oiw-vt-co-misc  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co     cotypemisc(O)  } 

oiw-vt-co-tcco  OBJECT  IDENTIFIER  ::  = 
{  oiw-vt-co     cotypetcco(4)  } 

Profiles  defined  by  OIW  VT  SIG: 

oiw-vt-pr-telnet-1988  OBJECT  IDENTIFIER  ::  = 

{oiw-vt-pr      telnet-1 988(0)  } 

oiw-vt-pr-transparent-1 988    OBJECT  IDENTIFIER  ::  = 
{oiw-vt-pr      transparent-1 988(1 )  } 

oiw-vt-pr-forms-1989  OBJECT  IDENTIFIER  ::  = 

{oiw-vt-pr      forms-1 989(2)  } 

oiw-vt-pr-x3-1989  OBJECT  IDENTIFIER  ::  = 

{oiw-vt-pr      x3-1989(4)  } 

oiw-vt-pr-generalizedTelnet   OBJECT  IDENTIFIER  ::  = 
{  oiw-vt-pr      generalizedTelnet(5)  } 

Control  Objects  defined  by  OIW  VT  SIG: 

oiw-vt-co-misc-sa  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co-misc       sa(0)  } 

oiw-vt-co-misc-ua  OBJECT  IDENTIFIER  ::  = 

{  oiw-vt-co-misc       ua(1)  } 
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oiw-vt-co-misc-st  OBJECT  IDENTIFIER  ::  = 

{  olw-vt-co-misc       st{2)  } 

olw-vt-co-misc-ut  OBJECT  IDENTIFIER  ::  = 

{  olw-vt-co-misc       ut(3)  } 

Object  kientifi^rj^  u&ed  by  the  S^mode  Paged  Profile: 

Ctoject  IdettllfJers  used  by  the  Snifiode  Paged  Profile  are  defined 
in  P0I3F 1 1 (AVT  23-S*mod0  Paged  Application  Profile.) 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Transaction  Processing  Special 
Interest  Group  (TPSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 
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technical  change  has  occurred  in  this  part  since  it  was  previously  presented. 

This  part  is  submitted  as  camera-ready  material.  Redline  and  Strikeout  were  not  used  in  this  text.  If  you 
have  any  questions  regarding  this  part,  please  call  the  TP  SIG  Chair. 
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Foreword 

This  part  of  the  Stable  Agreements  was  prepared  by  the  Transaction  Processing  Special  Interest 
Group  (TPSIG)  of  the  Open  Systems  Environment  (OIW).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part 
replaces  the  previously  existing  chapter  on  this  subject.  There  is  some  change  from  this  text  as 
previously  given.  References  are  made  to  other  sections  of  both  the  Working  and  Stable 
agreements. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published 
as  a  new  part.  Deleted  and  replaced  text  will  be  shown  as  .  New  and  replacement  text  will  be 
shown  as  shaded. 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems: 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International  Standardized  Profiles 
12061-1:  OSI  Distributed  Transaction  Processing. 

Parti:  INTRODUCTION 


1.  SCOPE 

Part  I  of  this  document  introduces  the  overall  structure  of  the  specification  of  the  OSI  TP  profiles. 
This  includes: 

a)  the  identification  of  the  Transaction  Processing  profiles  defined  in  this  document,  together 
with  the  Transaction  Processing  Profiles  Tree; 

b)  the  identification  of  the  various  Parts  v^^hich  constitute  this  document; 

c)  the  list  of  the  references  to  other  standards  relevant  to  the  definition  of  the  OSI  TP  profiles; 

d)  the  definitions  and  abbreviations  used  through  the  various  parts  of  this  document. 

2.  NORMATIVE  REFERENCES 

The  following  documents  contain  provisions  which,  through  reference  in  this  text,  constitute 
provisions  of  this  part  of  ISO/IEC  ISP  1 2061 .  At  the  time  of  publication,  the  editions  indicated 
were  valid.  All  documents  are  subject  to  revision,  and  parties  to  agreements  based  on  this  part 
of  ISO/IEC  ISP  1 2061  are  warned  against  automatically  applying  any  more  recent  editions  of  the 
documents  listed  below,  since  the  nature  of  references  made  by  ISPs  to  such  documents,  is  that 
they  may  be  specific  to  a  particular  edition.  Members  of  lEC  and  ISO  maintain  registers  of 
currently  valid  International  Standards  and  ISPs,  and  CCITT  maintains  published  editions  of  its 
current  Recommendations. 

The  following  ISO  standards  contain  provisions  for  the  definition  of  Transaction  Processing 
profiles  and  are  referenced  in  this  document: 


ISO/IEC  8327^  Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Basic  connection  oriented  session  protocol  specification 

ISO/IEC  DIS  8327-2       Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Basic  connection  oriented  session  PICS  Proforma. 

ISO/IEC  8327  AM3         Information  Processing  Systems-  Open  Systems  Interconnection  - 

Session.  Additional  resynchronisation  functionality. 

ISO/IEC  8650  Infonnation  Processing  Systems  -  Open  Systems  Interconnection 

Protocol  Specification  for  the  Association  Control  Service  Element. 


Second  edition  to  be  published 
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ISO/IEC  DIS  8650-2        Infonnation  Processing  Systems  -  Open  Systems  Interconnection  - 

PICS  Proforma  for  the  Association  Control  Service  Element. 

ISO/IEC  8823:1988        Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Connection  Oriented  Presentation  Protocol  Specification. 

ISO/IEC  DIS  8823-2       Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Connection  Oriented  Presentation  PICS  Proforma. 

ISO/IEC  8823  AM5         Information  Technology  -  Open  Systems  Interconnection  - 

Presentation.  Additional  resynchronisation  functionality. 

ISO/IEC  8825:1990        Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation 
One  (ASN.1). 

ISO/IEC  9805-1 :1990  Information  Technology  -  Open  Systems  Interconnection  - 

Protocol  Specification  for  the  Commitment,  Concurrency  and 
Recovery  service  element. 

ISO/IEC  DIS  9805-2       Information  Technology  -  Open  Systems  Interconnection  -  CCR  PICS 

Proforma. 

ISO/IEC  9805  AM2         Information  Technology  -  Open  Systems  Interconnection  -  CCR. 

Session  mapping  changes. 

ISO/IEC  1 0026-1 :1 992  Information  Technology  -  Open  Systems  Interconnection  - 

Distributed  Transaction  Processing:  Model. 

ISO/IEC  10026-2:1992  Information  Technology  -  Open  Systems  Interconnection  - 

Distributed  Transaction  Processing:  Service  Definition. 

ISO/IEC  10026-3:1992  Information  Technology  -  Open  Systems  Interconnection  - 

Distributed  Transaction  Processing:  Protocol  Specification. 

ISO/IEC  DIS  1 0026-4  Information  Technology  -  Open  Systems  Interconnection  - 

Distributed  Transaction  Processing:  PICS  Proforma 

ISO/IEC  1 1 1 88-1 2  Information  Technology  -  International  Standardized  Profile- 

Common  Upper  Layer  Requirements 


2  Currently  a  regional  workshop  document 
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081  TP  Profiles 


3. 


DEFINITIONS  AND  ABBREVIATIONS 


The  definitions  and  abbreviations  in  this  document  not  listed  in  this  section  are  found  in  the  TP 
model  document  (ISO/IEC  10026-1). 


AS- 

Conformance  class  for  Application  Supported  Transaction 

CP- 

Conformance  class  for  Chained  Provider  Supported  Transaction  Branches 

UP- 

Conformance  class  for  Unchained  Provider  Supported  Transaction  Branches 

FU- 

Functional  Unit 

ISP- 

International  Standardized  Profile 

PDU- 

Protocol  Data  Unit 

PPDU- 

Presentation  Protocol  Data  Unit 

SPDU- 

Session  Protocol  Data  Unit 

4.  NOTATION 

The  following  notations  are  used  in  the  tables  contained  in  Parts  2  to  4  of  this  ISP: 

1)  The  Item  Number  uniquely  identifies  each  capability,  parameter  or  field  within  the 
tables. 

2)  The  Parameter  column  provides  the  name  of  each  PDU  parameter. 

3)  The  Base  Standard  Status  column  indicates  static  requirements  as  defined  by  the 
base  standard  PICS  Proforma. 

The  notation  used  in  this  column  is  as  defined: 

-  in  the  OSI  TP  and  CCR  PICS  proforma  documents  for  the  OSI  TP  and  CCR 
related  tables; 

-  in  the  "Common  Upper  Layer  Requirement"  document  for  ACSE,  Presentation  and 
Session  related  tables. 

However,  as  the  ISP  is  not  intended  to  duplicate  the  information  contained  in  the 
documents  listed  above,  the  notation  has  been  simplified  as  follows: 

-  "C"  is  used  instead  of  any  "Cxxx",  where  xxx  is  an  integer. 

-  "O.n"  is  used  instead  of  any  "O.xxx",  where  xxx  is  an  integer. 

The  exact  definition  of  conditions  and  options  will  be  found  in  the  referenced 
documents. 

Note  that  the  "M"  and  "O"  notations  have  not  been  changed. 

Note  that  the  "D"  (default)  notation  may  be  used  in  this  column,  whilst  it  is  not  used 

in  the  PROFILE  Status  column  (included  within  the  M  notation). 

4)  The  Profile  ID  column,  if  present,  defines  how  this  parameter  is  used  by  a  specific 
profile. 

When  this  column  is  empty,  the  feature  applies  to  all  profiles  to  which  the  PDU 
applies. 

5)  The  Profile  Status  column  indicates  the  requirements  for  the  feature. 

These  requirements  are  valid  only  within  the  scope  of  a  specific  profile,  i.e.,  they 
apply  to  an  instance  of  an  implementation  operating  within  the  limits  specified  by  that 
profile.  For  instance,  the  notation  NA  used  for  some  feature  does  not  preclude  an 
Implementation  from  supporting  more  than  one  profile. 

M  =    f\1andatory.  The  feature  shall  be  supported,  i.e.  its  syntax  and  procedures 
shall  be  implemented  as  specified  in  the  base  standard  or  restricted  by  this 
ISP,  by  all  implementations  claiming  conformance  to  this  profile.  It  is  not 
necessary  that  a  mandatory  parameter  appears  in  all  instances  of 
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communication  when  either  a  default  value  has  been  specified,  or  this 
parameter  is  not  used  at  the  service  level. 

C  =    Conditional.  Any  feature  so  marked  must  be  implemented  under  the 

conditions  specified  in  the  profile  (e.g.  Mandatory,  Not  Applicable,  etc.,  for  a 
certain  instance  of  communication).  The  requirements  for  the  feature  then 
follow  the  rules  of  M,  NA,  etc. 

0  =    Optional.  This  is  an  optional  feature  in  the  base  standard.  It  is  left  to  the 

implementor  as  to  whether  this  feature  is  implemented.  Optional  features  for 
a  sender  need  not  be  implemented.  Optional  features  for  a  receiver  must  be 
recognized  and  may  be  processed  in  a  manner  consistent  with  the  base 
standard,  or  these  profiles.  If  implemented,  a  feature  will  be  subject  to 
conformance  testing. 

NA  =  Not  Applicable.  This  feature  is  not  defined  in  the  context  where  it  is 

mentioned  because  it  is  either  logically  or  physically  impossible  for  the  feature 
to  occur.  The  occurrence  of  this  feature  is  a  protocol  error.  It  will  be  handled 
as  specified  in  the  base  standard  or  this  ISP. 

1  =      Out  of  Scope.  This  is  an  optional  feature  of  a  base  standard.  However,  this 

feature  is  not  used  by  the  profile  nor  by  a  referencing  specification.  If  such  a 
feature  is  received  it  is  processed  according  to  local  procedures.  Local 
procedures  are  procedures  that  are  not  defined  by  any  base  standards  or 
profiles.  It  will  not  generate  a  protocol  error. 

There  are  presently  some  instances  where  features  marked  'M'  in  the  base 
standard  are  marked  T  in  this  profile.  This  has  been  done  only  because  the 
base  standard  PICS  are  not  yet  at  full  international  standard  status  and  it  is 
believed  that  the  markings  of  the  feature  will  change  during  progression  to  full 
international  standard  status.  It  is  intended  to  remove  all  such  inconsistencies 
with  the  base  standard  before  publication  of  this  ISP. 

*  =  U-ASE  defined.  This  is  an  optional  feature  of  a  base  standard.  This  feature 
may  or  may  not  be  used  by  a  referencing  specification.  How  it  is  used  is 
specified  by  the  referencing  specification.  When  a  default  value  is  given  in 
this  profile,  the  referencing  specification  may  choose  not  to  specify  any  value 
in  which  case,  the  default  value  applies.  A  default  value  is  specified  in 
parentheses  following  the  *,  e.g.,  *(l). 

O.N=  The  notation  O.N,  where  N  is  an  integer,  is  used  in  some  Status  Columns. 
This  notation  indicates  a  reference  to  a  unique  group  of  capabilities.  A  note 
(as  indicated  in  the  Notes  Column)  will  explain  the  exact  requirement  using 
one  of  the  following  forms: 

O.N  =  Support  of  exactly  one  of  these  items  is  required. 

O.N  =  Support  of  at  least  one  of  these  items  is  required. 
It  is  always  necessary  to  consult  the  con-esponding  note  to  determine  which 
situation  applies. 

When  status  for  sending  and  receiving  values  differ,  they  will  be  separated  by  a 
slash,  with  the  sender  on  the  left  and  receiver  on  the  right.  If  they  are  the  same 
there  will  only  be  one  status  in  the  cell.  The  integer  suffix  to  a  status  refers  to  a 
condition  that  will  be  found  either  immediately  following  that  table,  or  following  an 
earlier  table  in  the  same  part  of  this  ISP. 
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6)  The  T/LyV  Allowed  column  specifies  the  range  of  types,  length,  or  values  this 
parameter  can  assume  or  contain.  This  column  can  have  multiple  definitions  based 
on  which  profile  is  being  described.  When  multiple  definitions  are  possible  this 
column  will  be  defined  in  conjunction  with  the  Profile  ID  column.  The  notation  {} 
denote  no  bits  in  the  parameter's  value. 

7)  The  Notes  column  points  to  notes  following  the  table. 
5.       TAXONOMY  STRUCTURE 

5.1 .     GUIDELINES  FOR  SPLITTING  UP  THE  PROFILES 

This  subclause  specifies  which  functional  units  combine  to  form  each  profile.  Refer  to  the 
appropriate  part  of  this  ISP  for  the  specification  of  how  a  specific  profile  uses  a  PDU  and  its 
parameters.  Profiles  are  identified  by  a  coding  method  which  consists  of  two  levels,  but  which 
can  easily  be  expanded  as  future  needs  warrant.  The  first  level  indicates  the  conformance  class. 
The  second  level  indicates  whether  polarized  or  shared  control  is  used.  The  levels  are  defined 
as: 

Level  one: 

1 .  -  Application  Supported  transactions. 

2.  -  Provider  supported  unchained  transactions. 

3.  -  Provider  supported  chained  transactions. 

Level  two: 

1 .  -  Polarized  control. 

2,  -  Shared  control. 

5.2     TRANSACTION  PROCESSING  PROFILES  TREE 

The  figure  hereafter  gives  the  Transaction  Processing  Profiles  tree: 


Transaction  Processing 

ATP 

Application  Supported  Transactions 

ATPl 

Polarized  Control 

ATPll 

Shared  Control 

ATPl  2 

Provider  Supported  Unchained  Transactions 

ATP2 

Polarized  Control 

ATP21 

Shared  Control 

ATP22 

Provider  Supported  Chained  Transactions 

ATP3 

Polarized  Control 

ATP31 

Shared  Control 

ATP32 

The  first  level  of  this  decomposition  (ATPx)  corresponds  to  the  definition  of  the  three 
conformance  classes  defined  in  the  OSI  TP  standard.  The  second  level  (ATPxy)  corresponds  to 
the  selection  between  Polarized  Control  and  Shared  Control  for  each  of  the  conformance 
classes.  The  conformance  classes  and  the  functional  units  that  compose  them  are  summarized 
in  the  following  list: 
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1 .  ATP-1 1  Application  Supported  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL 

2.  ATP-21  Provider  Supported  Unchained  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL  +  COMMIT  +  RECOVERY  + 
UNCHAINED  TRANSACTION 

3.  ATP-31  Provider  Supported  Chained  Transactions  -  Polarized  Control: 
DIALOGUE  +  HANDSHAKE  +  POLARIZED  CONTROL  +  COMMIT  +  RECOVERY  + 
CHAINED  TRANSACTION 

4.  ATP-1 2  Application  Supported  Transactions  -  Shared  Control: 
DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL 

5.  ATP-22  Provider  Supported  Unchained  Transaction  -  Shared  Control: 

DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL  +  COMMIT  +  RECOVERY  + 
UNCHAINED  TRANSACTION 

6.  ATP-32  Provider  Supported  Chained  Transactions  -  Shared  Control: 

DIALOGUE  +  HANDSHAKE  (Optional)  +  SHARED  CONTROL  +  COMMIT  +  RECOVERY  + 
CHAINED  TRANSACTION 


Since  the  Profile  ID  is  not  carried  as  a  protocol  parameter,  implementations  may  determine  the 
profile  governing  a  particular  instance  of  communication  by  the  TP  Functional  Units  selected  for 
that  dialogue. 


This  part  of  ISO/IEC  ISP  12061  states  requirements  upon  implementors  to  achieve  Inter 
networking.  A  claim  of  conformance  to  one  of  parts  five  to  ten  of  this  ISP  is  a  claim  that  all 
requirements  in  the  relevant  base  standards  are  satisfied,  and  that  all  requirements  in  the 
relevant  parts  are  satisfied. 

Annexes  to  parts  two,  three  and  four  state  the  relationship  between  these  requirements  and 
those  of  the  base  standard. 

There  is  no  conformance  requirement  from  this  ISP  on  features  marked  "*"  in  the  annexes  of 
parts  two  and  four. 

Each  of  parts  five  to  ten  contain  specific  conformance  requirements  for  that  part. 


6. 
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INTRODUCTION 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
In  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  1 0. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session 
APDUs  for  each  of  the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  OSI  TP  protocol  for  the  profiles 
identified  in  Part  1  of  this  ISP. 


2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  contained  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  NOTATION 

The  notation  introduced  in  Part  1  of  this  ISP  applies  to  this  Part. 

5.  SUPPORT  OF  OSI  TP  PROTOCOL 

The  support  of  the  OSI  TP  protocol  is  as  described  in  Annex  A  (normative). 

The  structure  of  Annex  A  is  based  on  the  structure  of  Annex  A  of  ISO/IEC  10026-4,  in  particular 
in  the  numbering  of  the  clauses. 

When  a  clause  of  Annex  A  of  ISO/IEC  1 0026-4  is  not  relevant  to  the  profiles,  this  is  stated. 

6.  Conformance 

To  conform  to  the  OSI  TP  Protocol  used  in  any  of  the  profiles  in  this  ISP,  an  implementation  shall 
implement,  according  to  the  specifications  given  in  ISO/IEC  10026-3: 

1 .  All  the  mandatory  features  identified  in  Annex  A. 

2.  All  the  selected  optional  features,  as  identified  in  the  completed  TP  PICS. 
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ANNEX  A:  SUPPORT  OF  THE  OSI  TP  PROTOCOL  (Normative) 
A.1.  Identification 

No  restriction  is  applied  to  clause  A.I  of  ISO/IEC  10026-4  by  this  part  of  ISO/IEC  ISP  1 2061 . 
A.2.  CLAIMED  CONFORMANCE  TO  STANDARDS 

A.2.1.  ISO/IEC10026-3 

A.2.1 .1 .         VERSION  NUMBER(S) 

Answer  shall  be  "NONE". 

A.2.1.2.  GLOBAL  CONFORMANCE  CLAIM 

Answer  shall  be  "YES". 

A.2.2.   ISO/IEC  10026  AMENDMENTS 

Both  answers  shall  be  "NONE". 

A.2.3.   ISO/IEC  10026  TECHNICAL  CORRIGENDA 

Both  answers  shall  be  "NONE". 

Note:  At  the  time  of  the  approval  of  the  final  text  of  this  ISP,  no  Technical  Corrigenda  was 
approved  for  ISO/IEC  10026.  When  this  will  become  false,  the  present  ISP  will  be  corrected 
accordingly. 
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A.2.4.   CONFORMANCE  CLASS(ES)  SUPPORTED 


Table  1  -  CONFORMANCE  CLASSES  SUPPORTED 


ITEM# 

CONFORMANCE  CLASSES 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Application  Transaction  Branches 

O 

M 

NA 

NA 

M 

NA 

NA 

2 

Chained  Provider  Supported  Transaction 
Branches 

o 

NA 

NA 

M 

NA 

NA 

M 

3 

Unchained  Provider  Supported  Transaction 
Branches 

o 

NA 

M 

NA 

NA 

M 

NA 

NOTES 


Conformance  to  more  than  one  profile  may  be  claimed  for  an  implementation.  For  example, 
an  implementation  that  conforms  to  profile  21  will  often  be  capable  of  conforming  to  the 
corresponding  Profile  1 1 . 
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A.3.  FUNCTIONAL  UNITS,  LIMITS  AND  PROTOCOL  MECHANISMS 
A.3.1.   SUPPORT  OF  FUNCTIONAL  UNITS 

Table  2  -  SUPPORT  OF  FUNCTIONAL  UNITS 


ITEM* 

FUNCTIONAL  UNITS 

ISO/IEC  10026-4 

11 

21 

f 

31 

»ROFILI 
12 

ES 
22 

32 

NOTES 

AS 

CP 

UP 

1 

Dialogue 

M 

M 

M 

M 

M 

M 

M 

M 

M 

2 

Shared  Control 

O.n 

O.n 

O.n 

NA 

NA 

NA 

M 

M 

M 

3 

Polarized  Control 

O.n 

O.n 

O.n 

M 

M 

M 

NA 

NA 

NA 

4 

Handshake 

O 

O 

O 

M 

M 

M 

O 

O 

O 

5 

Oornmlt 

NA 

M 

M 

NA 

M 

M 

NA 

M 

M 

6 

Chained  Transactions 

NA 

M 

NA 

NA 

NA 

M 

NA 

NA 

M 

7 

Unchained  Transactions 

NA 

NA 

M 

NA 

M 

NA 

NA 

M 

NA 

8 

Recovery 

NA 

M 

M 

NA 

M 

M 

NA 

M 

M 

A.3.2.   PROTOCOL  MECHANISMS  IMPLEMENTED 
A.3.2.1 .  CONCATENATION/SEPARATION 

Table  3  -  SUPPORT  FOR  CONCATENATION/SEPARATION 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Concatenation 

O 

O 

O 

O 

O 

O 

O 

2 

Separation 

M 

M 

M 

M 

M 

M 

M 
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A.3.2.2.  ASSOCIATION  ESTABLISHMENT 


Table  4  -  ASSOCIATION  ESTABLISHMENT 


ITEM# 

ROLE 

ISO/I  EC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

C 

O 

M 

M 

O 

M 

M 

1,2,4 

2 

Acceptor 

C 

O 

M 

M 

O 

M 

M 

1,3.4 

3 

Reiector 

O 

M 

M 

M 

M 

M 

M 

5,6 

NOTES 


1  When  the  commitment  is  supported,  then  the  implementation  must  be  able  to  support  both 
the  association  initiator  and  acceptor  role  in  order  to  be  able  to  perform  recovery  adequately. 

2  The  initiator  role  here  implies  being  capable  of  issuing  an  A- ASSOC  I  ATE  request  and  being 
capable  of  receiving  an  A-ASSOCIATE  confirm. 

3  The  Acceptor  role  here  implies  being  capable  of  receiving  an  A-ASSOCIATE  indication  and 
being  capable  of  issuing  an  A-ASSOCIATE  response  with  a  positive  answer. 

4.  For  Profiles  1 1  and  12,  at  a  minimum,  the  association  establishment  initiator  role  or  the 
association  establishment  acceptor  role  shall  be  supported. 

5.  The  Rejector  role  here  implies  being  capable  of  receiving  an  A-ASSOCIATE  indication  and 
being  capable  of  issuing  an  A-ASSOCIATE  response  with  a  negative  answer. 

6.  Although  it  is  mandatory  to  be  able  to  reject  an  association,  note  that  in  some  particular 
environments  it  could  occur  that  the  reject  is  always  performed  by  some  lower  protocol 
machine  (e.g.  ACSE). 
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A.3.2.3.  SUPPORT  FOR  MANDATORY  AND  OPTIONAL  BIDDING 

Table  5  -  SUPPORT  FOR  MANDATORY  AND  OPTIONAL  BIDDING 


1  1  CM  IF 

10026-4 

PROFILES 

1 1 

CI 

Jl 

Vi\J  I  to 

1 

Initiator  with 

du  iiidiruaiuiy 

C 

01 00 

M 

M 

01 00 

M 

M 

2 

Initiator  with 
Bid  optional 

C 

O101 

O 

O 

C101 

O 

O 

3 

Responder  with 
Bid  mandatory 

C 

01 02 

M 

M 

01 02 

M 

M 

4 

Responder  with 
Bid  optional 

0 

0103 

M 

M 

01 03 

M 

M 

100  If  the  Initator  of  an  association  role  is  supported(A.3.2.2/1)  then  O  else  NA. 

101  If  the  Initiator  of  the  association  role  is  supported  (A.3.2.2/1)  then  M  else  NA. 

102  If  the  Acceptor  of  an  Association  role  is  supported(A.3.2.2/2)  then  O  else  NA. 

103  If  the  Acceptor  of  an  Association  role  is  supported(A.3.2.2/2)  then  M  else  NA. 
A.3.2.4.  CONTENTION 


Table  6  -  SUPPORT  FOR  CONTENTION  MANAGEMENT 


ITEM# 

ROLE 

ISO/1  EC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Contention  Winner 

O.n 

O 

M 

M 

O 

M 

M 

12 

2 

Contention  Loser 

O.n 

O 

M 

M 

O 

M 

M 

12 

NOTES 


1 .  When  the  commitnnent  is  supported,  in  order  to  enable  channel  establishment  (initiator  or 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  contention  winner  and 
contention  loser  roles. 

2.  For  profiles  1 1  and  1 2,  at  least  one  of  the  contention  winner  and  contention  loser  roles  shall 
be  supported. 

I 
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A.3.2.5.  BID  MECHANISM 

Table  7  -  SUPPORT  FOR  THE  BID  MECHANISM 


ITEM* 

ROLE 

ISO/I  EC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

C 

01 05 

M 

M 

01 05 

M 

M 

1,3 

2 

Responder 

C 

01 06 

M 

M 

01 06 

M 

M 

2,3 

105  If  the  Contention  Loser  role  is  supported  (A.3. 2.4/2)  then 

If  Associations  with  Bid  Mandatory  are  supported  (A.3. 2.3/1  or  A.3. 2.3/3) 
then  M  else  O 
else  NA 

106  If  the  Contention  Winner  role  is  supported  (A.3.2.4/1)  then  M  else  NA 
NOTES 

1 .  The  initiator  role  here  implies  being  capable  of  sending  a  TP-BID-RI  APDU  and  being 
capable  of  receiving  a  TP-BID-RC  APDU. 

2.  The  responder  role  here  implies  being  capable  of  receiving  a  TP-BID-RI  APDU  and  being 
capable  of  sending  a  TP-BID-RC  APDU  v^rith  a  positive  answer. 

3.  When  the  commitment  is  supported,  in  order  to  enable  channel  establishment  (initiator  and 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  bid  initiator  and  bid 
responder  roles. 

A.3.2.6.  DIALOGUE  ESTABLISHMENT 


Table  8  -  TP  DIALOGUE  ESTABLISHMENT 


ITEM# 

ROLE 

ISO/I  EO 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Initiator 

O.n 

O 

O 

O 

O 

O 

O 

1,3 

2 

Acceptor 

O.n 

O 

O 

O 

O 

O 

O 

2,3 

3 

Rejector 

M 

M 

M 

M 

M 

M 

M 

NOTES 


1 .   The  initiator  role  here  implies  being  capable  of  sending  a  TP-BEGIN-DIALOGUE-RI  APDU 
and  being  capable  of  receiving  a  TP-BEGIN-DIALOGUE-RC  APDU. 
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2.  The  Acceptor  role  here  implies  being  capable  of  receiving  a  TP-BEGIN-DIALOGUE-RI  APDU 
and  being  capable  of  sending  a  TP-BEGIN-DIALOGUE-RC  APDU  with  a  positive  answer. 

3.  For  each  of  the  profiles.at  least  one  of  the  Acceptor  or  initiator  roles  shall  be  implemented. 
A.3.2.7.         TRANSACTION  BRANCH  ESTABLISHMENT 


Table  9  -  TRANSACTION  BRANCH  ESTABLISHMENT 


ITEM# 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

InKlator 

C 

NA 

01 07 

01 07 

NA 

01 07 

01 07 

2 

Acceptor 

0 

NA 

0108 

O108 

NA 

0108 

0108 

107  If  the  implementation  is  capable  of  initiating  a  dialogue  (A.3. 2.6/1)  then  M  else  NA. 

108  If  the  irnplementaion  is  capable  of  accepting  a  dialogue  (A.3. 2.6/2)  then  M  else  NA. 
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A.3.2.8.          ROLES  IN  A  TRANSACTION  TREE  SUPPORTED 
Table  10  -  ROLES  IN  A  TRANSACTION  TREE  SUPPORTED 


ITEM  # 

ROLE 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

Root  Nod© 

0 

NA 

O 

O 

NA 

O 

O 

1 

2 

Intermediate  Node 

0 

NA 

O 

O 

NA 

O 

O 

1 

3 

Leaf  Node 

C 

NA 

01 09 

01 09 

NA 

01 09 

01 09 

1 

109  If  capable  of  acting  as  an  intermediate  node  then  M  else  O. 
NOTES 


1 .  An  implementation  must  be  capable  of  acting  as  either  a  root,  an  intermediate  or  a  leaf 
node. 

A.3.2.9.  SUPPORT  FOR  RECOVERY 

This  clause  does  not  apply  to  profiles  1 1  and  1 2. 


Table  11  -  SUPPORT  FOR  RECOVERY 


ITEM# 

ROLE 

ISO/IEO 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

One-Way 
recovery 

M 

NA 

M 

M 

NA 

M 

M 

2 

Two-Way 
Recovery 

O 

NA 

O 

O 

NA 

O 

O 
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A.4.   TP  PROTOCOL  -  GENERAL 

The  clause  A.4  in  ISO/IEC  1 0026-4  is  not  relevant. 
A.5.   TP  PROTOCOL  -  SUPPORT  OF  THE  DIALOGUE  FUNCTIONAL  UNIT 

A.5.1 .    DIALOGUE  FU  APDUS 


Table  12  -  TP  APDUS  FOR  THE  DIALOGUE  FU 


ITEM# 

PROTOCOL  DATA  UNIT 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-BEGIN-DIALOGUE-RI 

C 

C107/ 
M 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

CI  07/ 
M 

1 

2 

TP-BEGIN-DIALOGUE- 
RC 

c 

M/ 

CI  07 

M/ 

C107 

M/ 

CI  07 

M' 

C107 

M/ 

CI  07 

M/ 

CI  07 

2 

3 

TP-END-DIALOGUE-RI 

c 

M 

M 

NA 

M 

M 

NA 

4 

TP-END-DIALOGUE-RC 

c 

M 

M 

NA 

M 

M 

NA 

5 

TP-U-ERROR-RI 

M 

M 

M 

M 

M 

M 

M 

6 

TP-ABORT-RI 

M 

M 

M 

M 

M 

M 

M 

7 

TP-BID-RI 

C 

cm/ 

Clio 

M 

M 

cm/ 

C110 

M 

M 

8 

TP-BID-RC 

c 

Clio/ 
cm 

M 

M 

Clio/ 
cm 

M 

M 

9 

TP-INITIALIZE-RI 

c 

C112/ 
M 

M 

M 

C112/ 
M 

M 

M 

3 

10 

TP-INUIALIZE-RC 

c 

M/ 

C112 

M 

M 

M/ 

C112 

M 

M 

4 

110  If  the  implementation  is  capable  of  receiving  a  Bid  (A.3.2.5/2)  then  M  else  NA 

111  If  the  implementation  is  capable  of  initiating  a  Bid  (A.3.2.5/1)  then  M  else  NA 

112  If  the  implementation  is  capable  of  initiating  an  association  (A.3.2.2/1)  then  M  else  NA 

NOTES 

1 .   It  is  mandatory  for  every  implementation  to  receive  and  recognize  the  TP-BEGIN- 
DIALOGUE-RI  APDU  (ref  ISO/IEC  10026-3  13.1.2.1.C  and  1 3.1 .2.1  .f). 


September  1992  (Stable) 
PDISP  12061-2 
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2.  It  is  mandatory  for  every  implementation  to  be  capable  of  rejecting  a  TP-BEGIN-DIALOGUE- 
Rl  (ref  ISO/IEC  10026-3  13. 1.2. If). 

3.  It  is  mandatory  for  every  implementation  to  receive  and  recognize  the  TP-INITIALIZE-RI 
APDU  (ref  ISO/IEC  10026-3  13. 1.2.1. a). 

4.  It  is  mandatory  for  every  implementation  to  be  capable  of  rejecting  a  TP-INITIALIZE-RI 
APDU. 
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A.5.2.   TP-BEGIN-DIALOGUE-RI  APDU 

A.5.2.1.  DETAIL  OF  THE  DIALOGUE  FIELD  OF  TP-BEGIN-DIALOGUE- 

RI  APDU 

Table  13  -  TP-BEGIN-DIALOGUE-RI  for  Dialogue 


ITEM  # 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Initlating-TPSU-Tltle 

O/M 

M 

See  Table  14 

2 

Recipient-TPSU-ntle 

O/M 

M 

See  Table  14 

3 

Functional-Untts 

D 

11 

M 

(0,4) 

I     »  1 

12 

M 

{1)  OR  {1,4} 

• 

21 

M 

{0,3,4} 

22 

M 

{1,3}  or  {1,3,4} 

31 

M 

{0,2,4} 

32 

M 

{1.2}  or  {1,2,4} 

4 

Begin-Transaction 

C 

11,12,31,32 

NA 

21,22 

M 

5 

Confirmation 

D 

M 

6 

Correlator 

M 

M 

0..2**31-1 

7 

Last-Partner-identifler 

O/M 

M 

0..2**31-1 

1 

8 

User-Data 

O/M 

M 

0..10K  octets+ 

2 

NOTES 

1.  The  Last-Partner- Identifier  is  marked  M  because  an  implementation  shall  be  able  to  support 
more  than  one  dialogue  or  channel  on  an  association. 

2.  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data. 
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A.5.2.1 .1 .       DETAIL  OF  TPSU-TITLE  FIELDS  FOR  THE  DIALOGUE  FIELD 
OFTP-BEGIN-DIALOGUE-RI  APDU 

Table  14  -  Detail  of  TPSU-TITLE  fields  for  the  dialogue  field  of  TP-BEGIN-DIALOGUE-RI 

APDU 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

TYPE 

STATUS 

PROFILE  ID 

STATUS 

1I\J\  ALLOWED 

NOTES 

1 

T61  String 

O.n/M 

C113/M 

1..64  octets 

1 

2 

PrintableString 

O.a'M 

C113/M 

1  ..64  octets 

1 

3 

INTEGER 

O.a'M 

C113/M 

0..2**31-1 

1 

1 13  If  the  TPSU-TITLE  is  used  to  carry  a  RECIPIENT-TPSU-TITLE  value  then  M  else  O 
NOTES 

1 .   At  least  one  of  the  three  types  shall  be  supported  for  the  INITIATING-TPSU-TITLE. 
A.5.3.   TP-BEGIN-DIALOGUE-RC  APDU 

A.5.3.1.  DETAIL  OF  THE  DIALOGUE  FIELD  OF  TP-BEGIN-DIALOGUE- 

RC  APDU 


Table  15  -  TP-BEGIN-DIALOGUE-RC  for  Dialogue 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA^  ALLOWED 

NOTES 

1 

Functional-Units 

O/M 

M 

2 

Result 

D 

M 

3 

Diagnostic 

M 

M 

4 

Correlator 

M 

M 

0..2**31-1 

5 

User-Data 

O/N/1 

M 

0..10K  octets+ 

1 

NOTES 


1 .   The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data 
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A.5.4.   TP-END-DIALOGUE-RI  APDU 

This  APDU  does  not  apply  to  profiles  31  and  32. 

Table  16  -  TP-END-DIALOGUE-RI  for  Dialogue 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

V\JV  ALLOWED 

NOTES 

1 

Confirmation 

D 

11,12,21,22 

M 

A.5.5.   TP-ABORT-RI  APDU 

A.5.5.1 . .         DETAIL  OF  THE  USER  FIELD  OF  TP-ABORT-RI  APDU 

Table  17  -  TP-ABORT-RI,  for  user 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

User-Data 

O/M 

M 

0..10K  octets  + 

1 

NOTE 


1 .  The  receiver  shall  be  capable  of  receiving  at  least  1 0K  octets  of  user-data 

A.5.5.2.  DETAIL  OF  THE  PROVIDER  FIELD  OF  TP-ABORT-RI  APDU 

Table  18  -  TP-ABORT-RI,  for  provider 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

J/UV  ALLOWED 

NOTES 

1 

Provider-diagnostic 

M 

M 
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A.5.5.3.  TP-BID-RI  APDU 

Table  19 -TP-BID-RI 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VLN  ALLOWED 

NOTES 

1 

CCR-Token-Requested 

D 

11,12 

M 

False 

21.22,31,32 

M 

2 

Last-Parlner-ldentifier 

O/M 

M 

0..2**31-1 

A.5.6.   TP-BID-RC  APDU 

Table  20  -  TP-BID-RC 

ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UW  ALLOWED 

NOTES 

1 

Result 

D 

M 

A.5.7.   TP-INITIALIZE-RI  APDU 

Table  21  -  TP-INITIALIZE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

1 

Protocol-Version 

D 

M 

{version  1) 

2 

Oontention-Wlnner-Assignment 

D 

M 

3 

Bid-Mandatory 

D 

M 

4 

Recovery-Context-Handle 

0 

11,12 

1 

21,22,31,32 

O/M 

1  ..64  octets 

1 

NOTES 

1  It  is  optional  to  send  a  RECOVERY-CONTEXT-HANDLE  (RCH)  as  the  sender  may  have  no 
use  for  it.  It  is  mandatory  to  receive  an  RCH  and  be  able  to  send  it  on  the  TP-RECOVER-RI 
APDU. 
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A.5.8.   TP-INITiALIZE-RC  APDU 

Table  22  -  TP-INITIALIZE-RC 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUW  ALLOWED 

NOTES 

1 

Protocol-Version 

D 

M 

{version  1} 

2 

Recovery-Context-HarKlle 

OM 

11,12 

1 

21,22,31,32 

O/M 

1  ..64  octets 

1 

3 

Diaqnostic 

O/M 

M 

NOTES 

1    It  is  optional  to  send  a  Recovery-Context-Handle  (RCH)  as  the  sender  may  have  no  use  for 
it.  It  is  mandatory  to  receive  an  RCH  and  be  able  to  send  it  on  the  TP-RECOVER-RI  APDU. 
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A.6.  SUPPORT  OF  THE  SHARED  CONTROL  FUNCTIONAL  UNIT 

I 

A.6.1 .   SHARED  CONTROL  FUNCTIONAL  UNIT  APDUS 

This  clause  does  not  apply  to  profiles  1 1 ,  21  and  31 . 


Table  23  -  TP  APDUs  for  the  SHARED  Control  FU 


tTEM# 

PROTOCOL  DATA  UNITS 

ISO/lEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-U-ERROR-RC 

M 

NA 

NA 

NA 

M 

M 

M 

Part  1 5  -  Transaction  Processing 
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A.7.  SUPPORT  OF  THE  POLARIZED  CONTROL  FUNCTIONAL  UNIT 

Tills  clause  does  not  apply  to  profiles  12,  22  and  32.. 

A.7.1.   POLARIZED  CONTROL  FUNCTIONAL  UNIT  APDUS 


Table  24  -  TP  APDUs  for  the  Polarized  Control  FU 


ITEM# 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-GRANT-CONTROL-RI 

M 

M 

M 

M 

NA 

NA 

NA 

2 

TP-REOUEST-CONTROL-RI 

M 

M 

M 

M 

NA 

NA 

NA 
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A.8.   SUPPORT  OF  THE  HANDSHAKE  FUNCTIONAL  UNIT 

This  clause  applies  to  all  profiles. 

A.8.1 .    HANDSHAKE  FUNCTIONAL  UNIT  APDUS 


Table  25  -  TP  APDUs  for  the  Handshake  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-HANDSHAKE-RI 

M 

M 

M 

M 

C114 

0114 

C114 

2 

TP-HANDSHAKE-RC 

M 

M 

M 

M 

C114 

C114 

C114 

3 

TP-HANDSHAKE-AND-GRANT- 
CONTROL-RI 

C 

M 

M 

M 

NA 

NA 

NA 

4 

TP-HANDSHAKE-AND-GRANT- 
CONTROL-RC 

0 

M 

M 

M 

NA 

NA 

NA 

1 14  If  the  Handshake  FU  is  implemented  {A.3.1/4)  then  M  else  NA 
A.8.2.   TP-HANDSHAKE-RI  APDU 

This  APDU  is  not  applicable  for  profiles  12,  22  and  32  when  the  handshake  FU  is  not 
implemented. 


Table  26  -  TP-HANDSHAKE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

1 

Confirmation-Urgency 

0 

11,21.31 

NA 

12,22,32 

M 
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A.8.3.   TP-HANDSHAKE-AND-GRANT-CONTROL-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 2,  22  and  32. 

Table  27  -  TP-HANDSHAKE-AND-GRANT-CONTROL-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Confirmation-Urgency 

D 

11,21,31 

M 

A.9.  TP  PROTOCOL  -  SUPPORT  OF  THE  COMMIT  FUNCTIONAL  UNIT 

This  clause  applies  only  to  profiles  21 ,  22,  31  and  32. 
A.9.1.   COMMIT  FUNCTIONAL  UNIT  APDUS 


Table  28  -  TP  APDUs  for  Commit  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

TP-PREPARE-RI 

C 

NA 

C115 
/C116 

C115 
/C1 16 

NA 

C115 
/C1 16 

C115 
/C116 

2 

TP-DEFER-RI 

C 

NA 

C115 
/C1 16 

C115 
/C1 16 

NA 

C115 
/C1 16 

C115 
/C1 16 

3 

TP-HEURISTIC-REPORT-R! 

C 

NA 

C116 
/C1 15 

C116 
/C1 15 

NA 

C116 
/C1 15 

C116 
/C1 15 

4 

TP-TOKEN-GIVE-R! 

M 

NA 

M 

M 

NA 

M 

M 

11 5  If  the  implementation  is  capable  of  initiating  a  dialogue  (A.3.2.6/1)  then  M  else  NA 

116  If  the  implementation  is  capable  of  accepting  a  dialogue  (A.3.2.6/2)  then  M  else  NA 
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A.9.1 .1 .         TP-PREPARE-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  1 2. 

Table  29  -  TP-PREPARE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Data-Permitted 

C 

21,31 

M 

22,32 

NA 

A.9.2.   TP-DEFER-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  1 2. 

Table  30  -  TP-DEFER-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

TIUM  ALLOWED 

NOTES 

1 

Type 

D 

22,32 

M 

End-Dialogue 

21,31 

M 

A.9.3.   TP-HEURISTIC-REPORT-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  1 2. 

Table  31  -  TP-HEURISTIC-REPORT-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

lILN  ALLOWED 

NOTES 

1 

Heuristic-Reoort 

D 

M 
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A.9.4.   TP-TOKEN-GIVE-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  1 2. 


Table  32  -  TP-TOKEN-GIVE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Reason 

D 

M 

Regular,  Keep 

2 

Correlator 

M 

M 

23 


Part  15  -  Transaction  Processing 
TP 


September  1 992  (Stable) 
PDISP  12061-2 


A.10.    TP  PROTOCOL  -  SUPPORT  OF  THE  RECOVERY  FUNCTIONAL  UNIT 

This  clause  applies  only  to  profiles  21 ,  22,  31  and  32. 

A.10.1.  RECOVERY  FUNCTIONAL  UNIT  APDUS 


Table  33  -  TP  APDUs  for  Recovery  FU 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
10026-4 

ATP11 

ATP21 

ATP31 

ATP12 

ATP22 

ATP32 

NOTES 

1 

TP-BEGIN-DIALOGUE-RI 

M 

NA 

M 

M 

NA 

M 

M 

1 

2 

TP-BEGIN-DIALOGUE-RC 

M 

NA 

M 

M 

NA 

M 

M 

1 

3 

TP-BID-RI 

C 

NA 

M 

M 

NA 

M 

M 

1 

4 

TP-BID-RC 

C 

NA 

M 

M 

NA 

M 

M 

1,3 

5 

TP-RECOVER-RI 

M/C 

NA 

M 

/C1 17 

M 

/C1 17 

NA 

M 

/C1 17 

M 

/C1 17 

6 

TP-END-DIALOGUE-RI 

M 

NA 

M 

M 

NA 

M 

M 

7 

TP-TOKEN-PLEASE-RI 

C 

NA 

C118 

C118 

NA 

C118 

C118 

3 

8 

TP-INITIALIZE-RI 

M 

NA 

M 

M 

NA 

M 

M 

3 

9 

TP-INITIALIZE-RC 

M 

NA 

M 

M 

NA 

M 

M 

3 

10 

TP-TOKEN-GIVE-RI 

NA 

O 

O 

NA 

O 

O 

2 

117  if  the  recovery-context-handle  field  {A.5.7/4,  A.5.8/2)  is  supported  in  the  TP-INITIALIZE-RC 
and  TP-INITIALIZE-RI  APDUs  then  M  else  NA 

1 18  If  Two- Way  recovery  (A.3.2.9)  is  supported  then  M,  else  NA 
NOTES 

1  When  the  commitment  is  supported,  In  order  to  enable  channel  establishment  (initiator  or 
acceptor)  to  be  accepted,  it  is  required  to  be  able  to  support  both  the  bid  initiator  and  the  bid 
responder  roles. 

2  This  PDU  is  not  in  the  Recovery  FU  in  ISO/IEC  1 0026-4.  However  it  has  been  added  to  this 
ISP  as  required  for  support  of  Two-Way  recovery. 

3  This  APDU  is  specified  in  clause  A.5. 
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A.10.2.  TP-BEGIN-DIALOGUE-RI  APDU 

A.10.2.1.        DETAIL  OF  THE  CHANNEL  FIELD  OF  TP-BEGIN-DIALOGUE- 
RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  1 2. 


Table  34  -  TP-BEGIN-DIALOGUE-RI  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

1 

Functional-Units 

D 

M 

(5) 

2 

Correlator 

M 

M 

0..2**31-1 

3 

Channel-Utilization 

D 

M 

one-way-recovery 

O 

two-way-recovery 

4 

Last-Partner-ldenttfler 

O/M 

M 
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A.10.3.  TP-BEGIN-DIALOGUE-RC  APDU 

A.10.3.1.        DETAIL  OF  THE  CHANNEL  FIELD  OF  TP-BEGIN-DIALOGUE- 
RC  APDU 

This  table  does  not  apply  to  profiles  1 1  and  1 2. 


Table  35  -  TP-BEGIN-DIALOGUE-RC  (Recovery  FU) 


ITEM* 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

1 

Result 

D 

M 

2 

Diagnostic 

M 

M 

3 

Correlator 

M 

M 

0..2"31-1 

A.10.4.  TP-END-DIALOGUE-RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  12. 

Table  36  -  TP-END-DIALOGUE-RI  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

Confirmation 

D 

M 

False 

A.10.5.  TP-BID-RI  APDU 

This  table  does  not  apply  to  profiles  1 1  and  1 2. 

Table  37  -  TP-BID-RI  (Recovery  FU) 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VLN  ALLOWED 

NOTES 

1 

CCR-Tokens-Requested 

M 

2 

Last-  Partner-  Identifier 

O/M 

M 

0..2**31-1 
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A.10.6.  TP-RECOVER-RI  APDU 

This  APDU  does  not  apply  to  profiles  1 1  and  12. 

Table  38  -  TP-RECOVER-RI  APDU 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUS/  ALLOWED 

NOTES 

1 

Recovery -Context-Handle 

M 

M 

1..64  octets 

A.10.7.  TP-TOKEN-GIVE-RI  APDU 

Table  39  -  TP-TOKEN-GIVE-RI 


ITEM# 

ISO/IEC  10026-4 

PROFILE 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA^  ALLOWED 

NOTES 

1 

Reason 

D 

M 

Two-Way-recovery 

2 

Correlator 

C 

M 

NOTES 


This  table  is  not  in  ISO/IEC  10026-4.  However  it  has  been  added  to  this  ISP  as  required  for 
support  of  Two-Way  recovery. 
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Introduction 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
in  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 


Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  1 0. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session 
APDUs  for  each  of  the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Parts  2  to  4. 
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1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  CCR  protocol  for  the  profiles 
identified  in  Part  1  of  this  ISP. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  applies. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  Definitions  and  Abbreviations  listed  in  Part  1  of  this  ISP  applies. 

4.  NOTATION 

The  notation  desaibed  in  PART  1  of  this  ISP  Applies. 

5.  SUPPORT  OF  CCR  APDUs 

Annex  A  specifies  the  support  of  CCR  protocol. 

It  applies  to  profiles  21 ,  22,  31  and  32.  It  does  not  apply  to  profiles  1 1  and  12. 

6.  CONFORMANCE 

To  conform  to  the  OSI  CCR  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  9805: 

•  All  mandatory  features  identified  in  Annex  A. 

•  All  selected  optional  features,  as  identified  in  the  completed  CCR  PICS, 
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ANNEX  A:  CCR  PPU  Supports  (Normative)  

Temporary  Editor's  Note:  This  curent  Annex  A  is  based  on  a  version  of  the  CCR  PICS  Profomna 
which  is  based  on  Version  1  of  the  CCR  protocol.  It  is  expected  that  the  CCR  PICS  Proforma  will 
be  aligned  to  Version  2.  This  part  of  the  OSI  TP  ISP  will  be  updated  accordinly  during  the  DISP 
ballot  period.  Would  the  CCR  PICS  Proforma  not  be  aligned  on  time,  the  necessary  material  will 
be  inserted  in  the  OSI  TP  ISP. 

A.1  DATE  OF  STATEMENT 

No  restrictions  applied  to  clause  A.I  of  ISO/IEC  9805-2  by  this  ISP. 
A.2  IMPLEMENTATION  DETAILS 

No  restrictions  applied  to  clause  A.2  of  ISO/IEC  9805-2  by  this  ISP. 
A.3  ISO/IEC  9805-1 


The  answer  shall  be  "Version  2". 

A.4  AMENDMENTS  IMPLEMENTED 

Table  1  -  AMENDMENTS  IMPLEMENTED 


ITEM# 

Amendment 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1  1 

ISO/IEC  9805-1  Amendment  1 

NA 

NA 

NA 

NA 

NA 

NA 

2             1  ISO/IEC  9805-1  Amendment  2 

NA 

M 

M 

NA 

M 

M 

A.5  TECHNICAL  CORRIGENDA  IMPLEMENTED 

The  answer  shall  be  "None". 


At  the  time  of  approval  of  the  final  text  of  this  ISP  no  technical  corrigenda  was  approved  for 
ISO/IEC  9805.  When  this  condition  changes,  the  present  ISP  will  be  amended, 

A.6  GLOBAL  STATEMENT  OF  CONFORMANCE 
A.6.1  MANDATORY  FEATURES  IMPLEMENTED 

The  answer  shall  be  "Yes". 
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A.7  INITIATOR/RESPONDER  CAPABILITIES 

A.7.1  ATOMIC-ACTION-BRANCH  ESTABLISHMENT 


Table  2  -  ATOMIC-ACTION-BRANCH  ESTABLISHMENT  BY  PROFILE 


ITEM# 

Roles 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

SUPERIOR 

O 

NA 

C101 

C101 

NA 

O101 

Old 

1 

2 

SUBORDINATE 

o 

NA 

C102 

01 02 

NA 

01 02 

01 02 

1 

3 

MASTER 

o 

NA 

01 03 

01 03 

NA 

01 03 

01 03 

101  If  capable  of  acting  as  a  root  node  or  intermediate  node  then  M  else  I. 

102  If  capable  of  acting  as  a  leaf  node  or  intermediate  node  then  M  else  I. 

103  If  capable  of  acting  as  a  root  node  then  fvl  else  I. 
NOTES 

1 .   At  least  one  of  the  superior  or  subordinate  roles  must  be  implemented. 

A.7.2  SUPPORT  FOR  THE  CONCATENATION  MECHANISM 


Table  3  -  SUPPORT  FOR  THE  CONCATENATION  MECHANISM 


ITEM* 

Roles 

ISO/IEC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

SENDER 

O 

NA 

O 

M 

NA 

O 

M 

2 

RECEIVER 

M 

NA 

M 

M 

NA 

M 

M 

Tempoary  note  The  detail  of  the  markings  for  row  1 ,  sender  role  may  require  further  study.  A 
draft  technical  corrigendum  to  ISO/IEC  9805:1990  adds  procedures  for  the  combined  use  of 
the  C-COMMIT  and  C-BEGIN  services,  and  the  C-ROLLBACK  and  C-BEGIN  services. 
Support  for  concatenation  for  these  combined  services  may  not  be  optional.  An  issue  is  that 
TP  makes  no  use  of  the  C-ROLLBACK  and  C-BEGIN  services.  This  issue  may  apply  to 
ISO/IEC  DIS  9805-2  (CCR  PICS  Proforma). 

A.7.3  OTHER  IMPLEMENTATION  CAPABILITIES 

No  restriction  is  applied  to  clause  A.7.3  of  ISO/IEC  9805-2  by  this  ISP. 
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A.8  CCR  PROTOCOL  -  GENERAL 

This  subclause  details  TP's  requirements  of  ttie  CCR  protocol.  The  protocol  tables  described 
below,  except  for  the  CCR  PDU  Usage  by  Profile,  do  not  apply  to  TP  profiles  1 1  and  12. 

A.9  CCR  PROTOCOL 
A.9.1  CCR  PDUs 

This  table  specifies  the  support  level  of  each  PDU  with  respect  to  each  profile. 


Table  4  -  CCR  PDU  USAGE  BY  PROFILE 


ITEM* 

Protocol  Dala  Units 

ISO/I  EC 
9805-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

C-BEGIN-RI 

C 

NA 

0104 
/C105 

C104 
/C105 

NA 

01 04 
/CI  05 

CI  04 
/CI  05 

2 

C-BEGIN-RC 

o/c 

NA 

C105 
/CI  04 

C105 
/C104 

NA 

C105 
/C104 

CI  05 
/CI  04 

3 

C-PREPARE-RI 

O/C 

NA 

C104 
/C105 

C104 
/0105 

NA 

C104 
/C105 

CI  04 
/CI  05 

4 

C-READY-RI 

C 

NA 

C105 
/C104 

C105 
/C104 

NA 

C105 
/C104 

C105 
/CI  04 

5 

C-COMMrr-RI 

0 

NA 

01 04 
/CI  05 

C104 
/C105 

NA 

C104 
/C105 

C104 
/CI  05 

6 

C-COMMIT-RC 

0 

NA 

0105 
/CI  04 

0105 
/C104 

NA 

01 05 
/CI  04 

CI  05 
/CI  04 

7 

C-ROLLBACK-RI 

M 

NA 

M 

M 

NA 

M 

M 

8 

C-ROLLBACK-RC 

M 

NA 

M 

M 

NA 

M 

M 

9 

C-RECOVER-RI 

M 

NA 

M 

M 

NA 

M 

M 

10 

C-RECOVER-RC 

M 

NA 

M 

M 

NA 

M 

M 

104.  If  capable  of  acting  in  the  role  of  superior  then  M,  else  NA. 

105.  If  capable  of  acting  in  the  role  of  subordinate  then  M,  else  NA. 
A.9.2  C-BEGIN-RI 


Table  5  -  C-BEGIN-RI 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEKM 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  6 

2 

Branchd-Suffix  -  Octet  String 

O/M 

O/M 

1  ..  64  octets 

1 

Branch-Suffix  -  Integer 

O/M 

O/M 

0..2**31-1 

1 

3 

User  Data 

O/M 

NA 

NOTES 
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1 .   At  least  one  of  these  forms  must  be  supported. 

9.2.1.       ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-BEGIN  APDU. 


Table  6  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  Identifier  of  thie 
C-BEGIN  APDU 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

T/iyV  ALLOWED 

NOTES 

1 

Master's  Name 
AE-THIe-Form  1 
(Directory  name) 

C/M 

O/M 

1  ..  1024  octets 

1^ 

Master's  Name 
AE-Tltle-Form  2 
(Object  Id) 

C/M 

M 

1  ..  64  octets 

2 

2 

Atomic  Action  Id  - 
Suffix  -  Octet  String 

C/M 

G106/M 

1  ..  64  octets 

2 

Atomic  Action  Id.- 
Suffix  -  integer 

G/M 

C106/M 

0..2**31-1 

1 06  If  only  the  Master  role  is  supported  then  at  least  one  form  shall  be  supported,  otherwise  both 
forms  shall  be  supported. 

NOTES 

1.  It  is  optional  to  be  able  to  generate  a  Master's  name  AE-TITLE-FORM-1  (RDM),  but  it  is 
mandatory  to  be  able  to  propogate  it  when  received  from  a  superior  by  an  intermediate  node 

2.  The  maximum  length  of  the  Atomic-Action  Identifer  shall  be  1024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 

A.9.3  C-BEGIN-RC 


Table  7  -  C-BEGIN-RC 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

O/M 

NA 
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A.9.4  C-PREPARE-RI 

Table  8  -  C-PREPARE-RI 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES  j 

1 

User-data 

O/M 

M 

A.9.5  C-READY-RI 

Table  9  -  C-READY-RI 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

O/M 

NA 

A.9.6  C-COMMIT-RI 

Table  10  -  C-COMMIT-RI 


ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

1 

User-Data 

O/M 

M 

A.9.7  C-COMMIT-RC 

Table  1 1  -  C-COMMIT-RC 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VLN  ALLOWED 

NOTES 

1 

User-data 

O/M 

M 
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A.9.8  C-ROLLBACK-RI 

Table  12 -C-ROLLBACK-RI 


ISO/I  EC  9805-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

User-data 

O/M 

M 

A.9.9  C-ROLLBACK-RC 

Table  13  -  C-ROLLBACK-RC 


ISO/I  EC  9805-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

O/M 

M 

A.9.10  C-RECOVER-RI 

Table  14  -  C-RECOVER-RI 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUV  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  1 5 

2 

Branch  Identifier 

M 

M 

See  Table  1 S 

3 

Recovery  State 

M 

M 

See  Table  1 7 

4 

User  Data 

O/M 

M 
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A.9.10.1.  ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-RECOVER  Rl  APDU. 


Table  15  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  Identifier  of  tfie 
C-RECOVER-RI  APDU 

PROFiLE 

ITEM# 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Master's  Name 
AE-Tltle-Form  1 
(Directory  name) 

C 

O/M 

1  ..1024  octets 

1 

Master's  Name 
AE-Title-Form  2 
(Object  Id) 

c 

M 

1  ..  64  octets 

1 

2 

Atomic  Action  Id.- 
Sufflx  -  Octet  string 

c 

M 

1  ..  64  octets 

1 

Atomic  Action  Id.- 
Sufflx  •  integer 

0 

M 

0..2**31-1 

NOTES 

1 .  The  maximum  length  of  the  Atomic-Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  fy^aster's  Name  and 
suffix. 
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A.9.10.2.    BRANCH  IDENTIFIER 

This  clause  provides  detail  about  the  Branch  Identifier  field  of  the  C-RECOVER  Rl  APDU. 


Table  16  -  BRANCH  IDENTIFIER  DETAIL 


Branch  Identifier  of  tfie 
C-RECOVER-RI  APDU 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Superlor's-Name 
AE-Tttle-Form  1 
(Directory  name) 

C 

O/M 

1  ..1024  octets 

1 

Superior's-Name 
AE-Tltle-Form  2 
(Object  Id) 

c 

M 

1  ..  64  octets 

1 

2 

Branch"  Suffix  - 
Octet  string 

c 

M 

1  ..  64  octets 

1 

Brancii--  Suffix  - 
Integer 

c 

M 

0  ..2**31-1 

NOTES 

1 .  The  maximum  length  of  the  Branch  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Superior's  Name  and 
suffix. 
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A.9.10.3.  RECOVERY  STATE 

This  clause  provides  detail  about  the  RECOVERY-STATE  field  of  the  C-RECOVER  Rl  APDU. 

Table  17  -  RECOVERY-STATE 


Recovery-State  of  the 
C-RECOVER-RI  APDU 

PROFILE  j 

ITEM# 

STATE 

STATUS 

PROFILE  ID 

STATUS 

lILN  ALLOWED 

NOTES 

1 

Commit 

0 

C101/C102 

2 

Ready 

c 

C102/C101 

A.9.11  C-RECOVER-RC 

Table  18  -  C-RECOVER-RC 


BASE  STANDARD  ISO/IEC  9805-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

1 

Atomic  Action  Identifier 

M 

M 

See  Table  19 

2 

Branch  Identifier 

K/l 

See  Table  20 

3 

Recovery  State 

M 

M 

See  Table  21 

4 

User  Data 

OIU 

M 
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A.9.11.1.  ATOMIC-ACTION  IDENTIFIER 

This  clause  provides  detail  about  the  Atomic-Action  Identifier  field  of  the  C-RECOVER  RC  APDU. 


Table  19  -  ATOMIC-ACTION  IDENTIFIER  DETAIL 


Atomic-Action  Identifier  of  the 
C-RECOVER-RC  APDU 

PROFILE 

ITEM« 

PARAMETER 

STATUS 

PRORLE  ID 

STATUS 

ALLOWED 

NOTES 

1 

toaster's  Name 
AE-Tttle-Form  1 
(Directory  name) 

C 

O/M 

1  ..1024  octets 

1 

fvlaster's  Name 
AE-Titie-Form  2 
(Object  Id) 

c 

M 

1  ..  64  octets 

1 

2 

Atomic  Action  Id.- 
Sutfix  -  Octet  String 

c 

M 

1  ..  64  octets 

1 

Atomic  Action  Id.- 
Sufflx  -  Integer 

c 

M 

0  ..  2"31-1 

NOTES 

1 .   The  maximum  length  of  the  Atomic  Action  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Master's  Name  and 
suffix. 
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A.9.11.2.  BRANCH  IDENTIFIER 

This  clause  provides  detail  about  the  Branch  Identifier  field  of  the  C-RECOVER  RC  APDU. 


Table  20  -  BRANCH  IDENTIFIER  DETAIL 


Branch  Identifier  of  the 
C-RECOVER-RC  APDU 

PROFILE 

ITEM# 

PARAMrrER 

STATUS 

PRORLE  ID 

STATUS 

T/IJV  ALLOWED 

NOTES 

1 

Superlor's-Name 
AE-Title-Form  1 
(Directory  name) 

C 

O/M 

1  ..1024  octets 

1 

Superlor's-Name 
AE-Title-Form  2 
(Object  Id) 

0 

M 

1  ..  64  octets 

1 

2 

Branch-  Suffix  - 
Octet  string 

C 

1^ 

1  ..  64  octets 

1 

Branch"  Suffix  - 
Integer 

0 

M 

0  ..  2**31-1 

NOTES 


1 .  The  maximum  length  of  the  Branch  Identifer  shall  be  1 024  octets  for  Form  1  (Directory 
Name)  and  64  octets  for  Form  2  (object  ID).  This  length  includes  both  Superior's  Name  and 
suffix. 

A.9.11.3.  RECOVERY  STATE 

This  clause  provides  detail  about  the  RECOVERY-STATE  field  of  the  C-RECOVER  RC  APDU. 


Table  21  -  RECOVERY-STATE 


Recovery-Stale  of  the 
C-RECOVER-RC  APDU 

PROFILE 

ITEM# 

STATE 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

Done 

C 

CI  02 
'01 01 

2 

Unlmown 

c 

C101 
/C102 

3 

Retry-later 

M 

M 
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INTRODUCTION 


The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement 
outside  the  interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as 
transactions,  which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems 
Interconnection  (OSI)  a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by 
four  properties:  atomicity,  consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of 
messages,  but  that  the  exchanges  form  a  protected  indivisible  set. 

This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified 
In  M-IT-02  and  TR  10000. 


Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles 
specified  in  Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the 
profiles  specified  in  Part  5  to  1 0. 

Part  4  contains  the  specification  of  the  support  of  Session  ,  Presentation  and 
ACSEAPDUs  for  each  of  the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard. 
These  six  parts  make  reference  to  Paris  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  - 
International  Standardized  Profile  12061-4:  OSI  Distributed 
Transaction  Processing. 

Part  4:  Support  of  SESSION,  PRESENTATION  AND  ACSE  PDUs 


1.  SCOPE 

This  part  of  this  ISP  specifies  the  status  for  the  support  of  the  Session,  Presentation  and  ACSE 
protocols  for  the  profiles  identified  in  Part  1  of  this  ISP. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  contained  in  Part  1  of  this  ISP  apply  to  this  part. 

4.  NOTATION 

The  notation  described  in  PART  1  of  this  ISP  Applies. 

5.  SUPPORT  OF  SESSION  SPDUs 

Annex  A  specifies  the  support  of  Session  protocol. 

6.  SUPPORT  OF  PRESENTATION  PPDUs 

Annex  B  specifies  the  support  of  Presentation  protocol. 

7.  SUPPORT  OF  ACSE  APDUs 

Annex  0  specifies  the  support  of  ACSE  protocol. 


8.  CONFORMANCE 


To  conform  to  the  OSI  ACSE  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8650: 

•    All  mandatory  features  identified  in  Annex  C. 
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•  All  selected  optional  features,  as  identified  in  the  completed  ACSE  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP  -  ISO  11188-1. 

To  conform  to  the  OSI  Presentation  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8823: 

•  All  mandatory  features  identified  in  Annex  B. 

•  All  selected  optional  features,  as  identified  in  the  completed  Presentation  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP  -  ISO  11188-1. 

To  conform  to  the  OSI  Session  protocol  used  in  any  of  the  profiles  defined  in  this  ISP,  an 
implementation  shall  implement,  according  to  the  specifications  given  in  ISO/IEC  8327: 

•  All  mandatory  features  identified  in  Annex  A. 

•  All  selected  optional  features,  as  identified  in  the  completed  Session  PICS. 

•  All  restrictions  as  specified  in  the  Common  Upper  Layer  Requirements 
ISP  -  ISO  11188-1. 
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ANNEX  A:  Session  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  requirements  on  the  Session  protocol.  The  reader  should  consult  the 
Upper  Layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies  PDU 
parameters  necessary  for  this  ISP. 

A.1  SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


BASE  STANDARD  ISO/IEC  8327-2 

PROFILE 

1  1  CIVIF 

OAr  AblLI  1  T 

OTA  Tl  le 

rnUrlLt  lU 

OTA  Tl  IC 

O 1  A  1 Uo 

NU  1  to 

1 

KGrnel 

M 

M 

2 

Negotiated  Release 

O 

•(1) 

3 

Hatf  Duplex 

O.n 

NA 

3 

4 

Duplex 

O.n 

M 

5 

bxpeaitea  uata 

u 

(1) 

6 

Typed  Data 

O 

11,12 

21,22,31,32 

M 

7 

Capability  Data  Exchange 

c 

11,12 

•(') 

21,22.31,32 

NA 

3 

8 

Minor  Synchronize 

0 

11,12 

*(") 

21,22,31,32 

M 

9 

Symmetric  Synchronize 

o 

11,12 

21 ,22,31 ,32 

NA 

3 

10 

Maior  Synchronize 

o 

•d) 

11 

Resyncronize 

0 

11.12 

•(1) 

21,22.31,32 

M 

12 

Exceptions 

c 

NA 

1,3 

13 

Activity  Management 

0 

11,12 

21,22,31,32 

NA 

2.3. 

14 

Data  Separation 

c 

11,12 

21.22.31.32 

M 

NOTES 


1 .  Exceptions  FU  cannot  be  negotiated  because  Half  Duplex  is  not  allowed. 

2.  Activity  Management  FU  cannot  be  negotiated  for  these  profiles  because  the  Data 
Separation  FU  does  not  allow  the  Activity  Management  FU  to  also  be  selected. 

3.  Succesfully  accepting  these  functional  units  is  a  protocol  error.  If  any  of  the  following 
Functional  Units  is  proposed  on  a  CN  SPDU  the  Functional  Unit  shall  not  be  accepted  and 
the  corresponding  bit  shall  be  set  to  zero  on  the  Accept  SPDU. 
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A.2  ISO  8327  Protocol  Versions  Implemented 


Table  2  -ISO  8327  PROTOCOL  VERSIONS  IMPLEMENTED 


BASE  STANDARD  ISO/IEC  8327  -2 

PROFILE 

ITEM# 

CAPABILITY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Version  1 

O 

1 

2 

Version  2 

O 

M 

A.3  PROTOCOL  MECHANISMS 


Table  3-  PROTOCOL  MECHANISMS 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

CAPABILITY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Use  of  Transport  Expedited  Data 

O 

O 

2 

Reuse  of  Transport  Connection 

O 

3 

Basic  Concatenation 

M 

M 

4 

Extended  Concatenation 

O 

1 

5 

Segmentation 

O 

•(I) 

6 

Segmentation  of  Unlimited  User  Data 

O 
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A.4  INITIATOR/RESPONDER  CAPABILITIES 


Table  4  -  INITIATOR/RESPONDER  CAPABILITIES 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

CAPABILITY 

STATUS 

PROFILE  ID 

STATUS 

NOTES 

1 

Initiator 

0 

C101 

2 

Responder 

O 

M 

101.  If  capable  of  initiating  an  Association  then  M,  else  I. 

A.5  SESSION  PROCEDURES  USAGE  BY  PROFILE 

This  table  specifies  the  supported  level  of  each  Session  PDU  with  respect  to  each  profile. 


Table  5  -  KERNEL  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Connect  (CN) 

C/C 

C103 
M 

CI  03 
/M 

CI  03 
M 

CI  03 
/M 

CI  03 
/M 

CI  03 
/M 

2 

Overflow  Accept(OA) 

C 

1 

1 

1 

1 

1 

1 

3 

Connect  Data  Overflow(CDO) 

c 

1 

1 

1 

1 

1 

1 

4 

Accept(AC) 

C/C 

CI  04 

/CI  03 

C104 
/CI  03 

C104 
/C103 

C104 
/CI  03 

CI  04 

/C103 

CI  04 
/C103 

5 

Refuse(RF) 

C/C 

M 

/CI  03 

M 

/CI  03 

M 

/CI  03 

M 

/CI  03 

M 

/CI  03 

M 

/CI  03 

6 

Finish(FN) 

O/C 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 
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Table  5  -  continued 


ITEM  # 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

7 

Disconnect(DN) 

O 

M 

/CI  05 

M 

/CI  05 

M 

/CI  05 

M 

/C105 

M 

/CI  05 

M 

/CI  05 

8 

Abort(AB) 

M 

M 

M 

M 

M 

M 

M 

9 

Abort  Accept(AA) 

0 

CI  06 

C106 

CI  06 

C106 

CI  06 

CI  06 

10 

Data  Transfer(DT) 

O/C 

M 

M 

M 

M 

M 

M 

11 

Prepare(PR) 

c/c 

CI  07 

CI  07 

CI  07 

C107 

CI  07 

CI  07 

103.  If  capable  of  initiating  an  Association  then  M,  else  I. 

104.  If  capable  of  responding  to  a  AARQ  APDU  then  M,  else  I. 

105.  If  capable  of  initiating  a  FINISH  then  M,  else  NA. 

106.  If  reusing  T-Connection  then  M,  else  I. 

107.  If  transport  expedited  available  then  M,  else  NA. 

Table  6  -  NEGOTIATED  RELEASE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Not  Finished{NF) 

O/M 

* 

2 

Give  Tokens(GT) 

O 

1 

3 

Pleas©  Toi<ens(PT) 

O/M 

• 

• 

1 

NOTES 


1 .  These  PDUs  are  marked  *  in  this  table  because  the  Negotiated  Release  FU  is  marked  *  in 
Table  1.  These  PDUs  may  be  used  elsewhere  in  different  ways. 
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Table  7  -  HALF  DUPLEX  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Give  Tok0ns(GT) 

O 

NA 

NA 

NA 

NA 

NA 

NA 

1 

2 

Please  Tokens(PTl 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

NOTES 


1 ,   These  PDUs  are  marke  NA  in  this  table  because  the  Half  Duplex  FU  is  marked  NA  in  Table 
1.  These  PDUs  may  be  used  else  where  in  different  ways. 

DUPLEX  FUNCTIONAL  UNIT  PROCEDURES 

No  additional  SPDUs  (this  clause  is  present  for  completeness). 


Table  8  -  EXPEDITED  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Expedited  Data{EX) 

O/M 

• 

• 

* 
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Table  9  -  TYPED  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Typed  DatafTD) 

O/M 

M 

M 

M 

M 

Table  10  -  CAPABILITY  DATA  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Capabllltv  Data(CD)) 

O/M 

NA 

NA 

NA 

NA 

1 

2 

Capability  Data  Ad<(CDA) 

M/C 

NA 

NA 

NA 

NA 

1 

NOTES 


1 .  Because  the  Capability  Data  FU  shall  never  be  selected  on  a  Session  Connection  for  Profiles 
21 ,  22,  31 ,  and  32,  the  Session  Protocol  Machine  will  generate  a  protocol  error  when  a  CD  or 
CDA  SPDU  is  received  in  these  profiles. 

Table  11  -MINOR  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Minor  Sync  Point(MIP) 

O 

* 

M 

M 

M 

M 

2 

Minor  Sync  Point  Ack(MIA) 

O/C 

M 

M 

M 

M 

3 

Give  Tokens(GT) 

O 

• 

M 

M 

M 

M 

4 

Please  Tokens{PT) 

O/M 

M 

M 

M 

M 
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Table  12  -SYMMETRIC  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Minor  Sync  Point(lvllP) 

O 

NA 

NA 

NA 

NA 

1 

2 

Minor  Sync  Point  Ack(MIA) 

o/c 

NA 

NA 

NA 

NA 

1 

NOTES 


1 .   Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  on  a  Session  Connection  for 
Profiles  21 ,  22,  31 ,  and  32,  the  MIP  and  MIA  SPDUs  have  been  marked  NA.  They  may  be 
used  differently  elsewhere. 


Table  13  -MAJOR  SYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Major  Sync  Point(MAP) 

O/M 

2 

Major  Sync  Point  Ack(MAA) 

M/C 

3 

Give  Tokens(GT) 

O 

• 

• 

1 

4 

Please  Tokens(PT) 

O/M 

1 

5 

Prepare(PR) 

C/C 

1 

NOTES 


1 .   Because  the  Major  Synchronize  FU  has  been  marked  *  in  Table  1 ,  these  PDUs  have  been 
marked  *.  They  may  be  used  differently  elsewhere. 


Table  14  -RESYNCHRONIZE  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


tTEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

RESYNGHRONIZE{RS) 

O/M 

• 

M 

M 

M 

M 

1 

2 

RESYNCHRONIZE  Ack(RA) 

M/C 

• 

M 

M 

• 

M 

M 

1 

3 

Prepare(PR) 

G/C 

01 07 

01 07 

* 

01 07 

01 07 

1 

9 


Part  1 5  -  Transaction  Processing 
Session 


September  1 992  (Stable) 
PDISP  12061-4 


NOTES 

1 .   Because  the  ReSynchronize  FU  has  been  marked  in  Table  1  with  *  for  Profiles  1 1  and  12 
these  PDUs  have  been  marked  with  *  in  this  table.  They  may  be  used  differently  elsewhere. 


Table  15  -EXCEPTIONS  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Exception  Report(ER) 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

2 

Exception  Data(ED) 

O/M 

NA 

NA 

NA 

NA 

NA 

NA 

1 

NOTES 


1 .   Because  the  ExceptlonFU  shall  never  be  selected  for  a  Session  Connection,  the  Session 
Protocol  Machine  will  generate  a  protocol  error  when  an  ER  or  ED  SPDU  is  received. 


Table  16  -ACTIVITY  MANAGEMENT  FUNCTIONAL  UNIT  PROCEDURES  USAGE  BY 

PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/IEC 
8327-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

Activity  Start(AS) 

O/M 

NA 

NA 

NA 

NA 

2 

2 

Activity  Resume(AR) 

O/M 

NA 

NA 

NA 

NA 

2 

3 

Activity  Interrupt(AI) 

O/M 

* 

NA 

NA 

« 

NA 

NA 

2 

4 

Activity  Interrupt  Ack(AIA) 

M/C 

• 

NA 

NA 

NA 

NA 

2 

5 

Activity  Discard(AD) 

O/M 

NA 

NA 

* 

NA 

NA 

2 

6 

Activity  Discard  Ack(ADA) 

M/C 

NA 

NA 

NA 

NA 

2 

7 

Activity  End(AE) 

O/M 

NA 

NA 

• 

NA 

NA 

2 

8 

Activity  End  Ack(AEA) 

M/C 

• 

NA 

NA 

• 

NA 

NA 

2 

9 

Prepare(PR) 

C/C 

• 

NA 

NA 

* 

NA 

NA 

2,3 

10 

Give  Tokens{GT) 

O 

* 

NA 

NA 

* 

NA 

NA 

2,3 

11 

Please  Tokens(PT) 

O/M 

• 

NA 

NA 

NA 

NA 

2,3 

12 

Give  Tokens  Conflrm(GTC) 

O/M 

• 

NA 

NA 

NA 

NA 

1^ 

13 

Give  Tokens  Confirm  Ack(GTA) 

O/M 

NA 

NA 

NA 

NA 

1,2 

NOTES 


1 .  The  Give  tokens  confirm  and  Ack  are  a  result  of  the  control  give  service  and  require  the 
activity  management  FU. 

2.  Because  the  Activity  Management  FU  shall  never  be  selected  on  a  Session  connection  for 
profiles  21 ,  22,  31  and  32,  the  Session  Protocol  Machine  will  generate  a  protocol  error  when 
the  SPDU  is  received  in  these  Profiles. 

3.  Because  the  Activity  Management  FU  has  been  marked  in  Table  1  with  *  or  NA  the  PDUs 
have  been  marked  with  *  or  NA  in  this  table.  They  may  be  used  differently  elsewhere. 
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A.6  SUPPORTED  PARAMETERS  OF  SESSION  PDUs. 
A.6.1  CONNECT  (ON)  SPDU 


Table  17  -  CONNECT  (CN)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

PGI  Connection  Identifier 

1 

PGI  default  (absent) 

O/M 

1 

2 

PGI  default  (emptv) 

O/M 

1 

3 

Galling  SS-User  Reference 

O/M 

1 

4 

Common  Reference 

O/M 

1 

5 

Additional  Reference  Info 

O/M 

1 

PGI  Connect/ Accept  Item 

6 

PGI  default  (absent) 

O/M 

1 

7 

PGI  default  (empty) 

O/M 

1 

8 

PGI  default  (not  empty) 

O/M 

M 

9 

Protocol  Options 

C/M 

l/M 

10 

TSDU-MaxImum-size 

O/M 

l/M 

11 

Version  Number 

O/M 

M 

Version  2 

12 

Initial  Serial  Number 

O/M 

11,12 

21 ,22,31 ,32 

M 

13 

Tol<en  Setting  Item 

O/M 

11,12 

21,22,31,32 

M 

14 

Second  Initial  Serial  Number 

0/C 

11.12 

C108 

21,22,31,32 

1 

1 
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Table  17  -  continued 


ISO/lEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

IIW  ALLOWED 

NOTES 

Single  Items 

it) 

Session  User  Requirements 

O/M 

M 

16 

Calling  Session  Selector 

O/M 

M 

17 

Called  Session  Selector 

O/M 

M 

18 

PGI  "User  Data" 

O/M 

M 

19 

Data  Overflow 

C/C 

1 

20 

PGI  "Extended  User  Data" 

C/C 

M 

108.     If  Symmetric-Sync  supported  then  O  else  I. 
NOTES 

1 .   Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  for  a  Session  connection  for 
Profiles  21 ,  22,  31  and  32,  the  Session  Protocol  machine  will  ignore  the  Second  Initial  Serial 
Number  parameter  if  it  is  present  on  a  CN  SPDU  in  Profiles  21 ,  22,  31 ,  and  32. 


A.6.2  OVERFLOW  ACCEPT  (OA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.3  CONNECT  DATA  OVERFLOW  (CDO)  SPDU 

This  SPDU  Is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
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A.6.4  ACCEPT  (AC)  SPDU 


Table  18  -  ACCEPT(AC)  SPDU 


ISO/iEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

PGI  Connection  Identifier 

PGI  default  (absent) 

O/K/1 

2 

PGI  default  (empty) 

O/M 

Calling  SS-User  Reference 

O/M 

A 

Common  Reference 

O/M 

5 

Additional  Reference  Info 

O/M 

PGI  Connect/ Accept  Item 

6 

PGI  default  (absent) 

O/M 

NA 

1 

7 

PGI  default  (empty) 

O/M 

NA 

1 

8 

PGI  default  (not  empty) 

O/M 

M 

9 

Protocol  Options 

C/M 

1 

10 

TSDU-Maximum-size 

O/M 

m 

11 

Version  Number 

C/M 

M 

Version  2 

12 

Initial  Serial  Number 

O/M 

11,12 

21,22,31,32 

M 

13 

Token  Setting  Item 

OM 

11,12 

21,22,31,32 

M 

14 

Second  Initial  Serial  Number 

C/C 

11,12 

CI  08 

21,22.31,32 

1 

2 

Single  Items 

15 

Token  Item 

O/M 

O/M 

16 

Session  User  Requirements 

O/M 

M 

17 

Calling  Session  Selector 

O/M 

M 

18 

Called  Session  Selector 

O/M 

M 

19 

PGI  "User  Data" 

O/M 

M 

20 

Enclosure  Item 

C 
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NOTES 

1 .  Because  Session  Version  2  shall  be  selected,  the  Session  Protocol  Machine  will  generate  a 
protocol  error  when  the  PGI  Connect/Accept  item  is  absent  or  empty. 

2.  Because  the  Symmetric  Synchronize  FU  shall  never  be  selected  for  a  Session  connection  for 
Profiles  21 ,  22,  31  and  32,  the  Session  Protocol  Machine  will  ignored  the  Second  Initial 
Serial  Number  parameter  if  it  is  present  on  an  AC  SPDU  in  Profiles  21 ,  22,  31 ,  and  32. 

A.6.5  REFUSE  (RF)  SPDU 


Table  19  -  REFUSE  (RF)  SPDU 


ISOMEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

J/UW  ALLOWED 

NOTES 

1 

PGI  default  (empty) 

O/M 

2 

PGI  default  (not  empty) 

O/M 

3 

Called  SS-User  Reference 

O/M 

4 

Common  Reference 

O/M 

5 

Additional  Reference  Info 

O/M 

Single  Items 

6 

Transp>ort  Disconnect 

O/M 

O/M 

9 

Session  User  Requirements 

O/M 

M 

10 

Version  Number 

O/M 

M 

11 

Reason  Code 

O/M 

M 

12 

Enclosure  Item 

c 

* 

A.6.6  FINISH  (FN)  SPDU 


Table  20  -  FINISH  (FN)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

J/LfW  ALLOWED 

NOTES 

1 

TransF>ort  Disconnect 

O/M 

O/M 

2 

PGI  "User  Data" 

O/M 

M 

3 

Enclosure  Item 

c/c 

• 
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A.6.7  DISCONNECT  (DN)  SPDU 

Table  21  -  DISCONNECT  (DN)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

PGI  "User  Data- 

O/M 

M 

2 

Enclosure  Item 

C/C 

A.6.8  NOT  FINISHED  (NF)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.9  ABORT  (AB)  SPDU 

Table  22  -  ABORT  (AB)  SPDU 


ISO/IEC  8327-2 

PROFILE 

!TEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Transport  Disconnect 

M 

M 

Z 

Reflect  Parameter  Values 

O/M 

1 

3 

PGI  "User  Data" 

O/M 

M 

4 

Enclosure  Item 

C/C 

A.6.10  ABORT  ACCEPT  (AA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.11  DATA  TRANSFER  (DT)  SPDU 

Table  23  -  DATA  TRANSFER  (DT)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

User  Information  Field 

O/M 

M 

2 

Enclosure  Item 

c/c 

A.6.12  EXPEDITED  DATA  (EX)  SPDU 
This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
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A.6.13  TYPED  DATA  (TD)  SPDU 

Table  24  -  TYPED  DATA  (TD)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

lILN  ALLOWED 

NOTES 

1 

Enclosure  Item 

C/C 

2 

User  Information  Field 

O/M 

M 

A.6.14  CAPABILITY  DATA  (CD)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.15  CAPABILITY  DATA  ACK  (CDA)  SPDU 


This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  1 2  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 
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A.6.16  GIVE  TOKENS  (GT)  SPDU 


This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  25  -  GIVE  TOKENS  (GT)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

J/Uy  ALLOWED 

NOTES 

1 

Token  Item 

O/M 

M 

Minor  Sync 

Other  Tokens 

2 

PGI  "User  Data" 

C/C 

M 

3 

Enclosure  Item 

C/C 

A.6.17  PLEASE  TOKENS  (PT)  SPDU 


This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  26  -  PLEASE  TOKENS  (PT)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUV  ALLOWED 

NOTES 

1 

Token  Item 

O/M 

M 

Minor  Sync 

Otiier  Tokens 

2 

PGI  "User  Data" 

O/M 

M 

3 

Enclosure  Item 

C/C 

• 
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A.6.18  MINOR  SYNC  POINT  (MIP)  SPDU 

This  PDU  is  not  used  by  Profiles  1 1  and  12. 

Table  27  -  MINOR  SYNC  POINT  (MIP)  SPDU 


ISO/IEC  8327-2 

PROFILE 

!TEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

lILN  ALLOWED 

NOTES 

1 

Sync  Type  Item 

O/M 

M 

2 

Serial  Number 

M 

M 

3 

PGI  "User  Data" 

O/M 

M 

4 

Enclosure  Item 

C 

M 

A.6.19  MINOR  SYNC  POINT  ACK  (MIA)  SPDU 

This  PDU  is  not  used  by  Profiles  11  and  12. 

Table  28  -  MINOR  SYNC  POINT  ACK  (MIA)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

HUM  ALLOWED 

1 

Serial  Number 

M 

M 

NOTES  1 

2 

PGI  "User  Data" 

O/M 

M 

3 

Enclosure  Item 

C/C 

* 

A.6.20  MAJOR  SYNC  POINT  (MAP)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.21  MAJOR  SYNC  POINT  ACK  (MAA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
A.6.22  RESYNCHRONIZE  (RS)  SPDU 

This  PDU  is  not  used  by  TP  for  profiles  1 1  and  12. 
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Table  29  -  RESYNCHRONIZE  (RS)  SPDU 


ISO/IEC  8327-2 

PROFILE 

ITPMif 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Enclosure  Item 

0 

2 

Token  Setting  Item 

O/M 

M 

Minor  Sync 

Other  Tokens 

3 

Resync  Type 

O/M 

M 

4 

Serial  Number 

O/M 

M 

5 

Second  Resync  Type 

C 

1 

6 

Second  Serial  Number 

C 

1 

7 

PGI  "User  Data" 

O/M 

M 

A.6.23  RESYNCHRONIZE  ACK  (RA)  SPDU 


Table  30  RESYNCHRONIZE  ACK  (RA)  SPDU 


This  PDU  is  not  used  by  TP  for  profiles  1 1  and  1 2. 


ISO/IEC  8327-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LyV  ALLOWED 

NOTES 

1 

Enclosure  Item 

C 

2 

Token  Setting  Item 

O/M 

32 

M 

Minor  Sync 

Other  Tokens 

3 

Resync  Type 

O/M 

1 

4 

Serial  Number 

O/M 

M 

5 

Second  Resync  Type 

C/C 

1 

6 

Second  Initial  Serial  Number 

C/C 

1 

7 

PGI  "User  Data" 

O/M 

M 
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A.6.24  PREPARE  (PR)  SPDU 

Table  31  -  PREPARE  (PR)  SPDU 
This  PDU  is  not  used  by  TP  for  profiles  1 1  and  1 2. 


ISO/IEC  8327-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUy  ALLOWED 

NOTES 

1 

Prepare  Type 

M 

M 

2 

Resync  Type 

C 

1 

3 

Second  Resync  Type 

C 

1 

A.6.25  EXCEPTION  REPORT  (ER)  SPDU 


This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  prohibited 
A.6.26  EXCEPTION  DATA  (ED)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  prohibited 
A.6.27  GIVE  TOKENS  CONFIRM  (GTC)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  Is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.28  GIVE  TOKENS  CONFIRM  ACK  (GTA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.29  ACTIVITY  START  (AS)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.30  ACTIVITY  RESUME  (AR)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 
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A.6.31  ACTIVITY  INTERRUPT  (AI)SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.32  ACTIVITY  INTERRUPT  ACK  (AIA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 

A.6.33  ACTIVITY  DISCARD  (AD)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited 

A.6.34  ACTIVITY  DISCARD  ACK  (ADA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.35  ACTIVITY  END  (AE)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  1 2  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 

A.6.36  ACTIVITY  END  ACK  (AEA)  SPDU 

This  SPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  in  profiles  1 1  and  12  is  not  specified  by  this 
ISP;  however,  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited 
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ANNEX  B:  Presentation  PROTOCOL  PDUs  (Normative) 


B.1.  PRESENTATION  SERVICE  PARAMETERS 

This  subclause  details  TP's  requirements  on  the  presentation  protocol.  The  reader  should 
consult  the  Upper  Layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only 
specifies  PDU  parameters  necessary  for  this  ISP. 

B.1.2.  CONNECTION  INITIATOR  or  RESPONDER  CAPABILITIES 


Table  1  -  CONNECTION  INITIATOR  OR  RESPONDER  CAPABILITIES 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUW  ALLOWED 

NOTES 

1 

Initiator 

O 

C101 

2 

Responder 

O 

M 

101.     If  capable  of  initiating  an  association  then  M,  else  I. 
B.1.3.  PROTOCOL  MECHANISMS 

Table  2  -PROTOCOL  MECHANISMS 


ISO/IEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

1 

X.410  (1984) 

O 

NA 

1 

2 

Normal 

O 

M 

I 
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NOTES 

1 .   Implementations  ttiat  support  X.41 0  mode  shall  respond  to  a  CP  PPDU  proposing  X.41 0- 
1984  mode  with  an  S-U-ABRT;  where  the  user  data  contains  an  Abort  Information  data 
element  (defined  in  X.410),  which  contains  an  AbortReason  (type  INTEGER)  of  value  4 
(protocol  error).  Implementations  that  do  not  support  X.41 0-1 984  mode  shall  respond  with 
either  a  Presentation-Provider  abort  or  a  Presentation-Provider  Reject. 

B.1.4.  FUNCTIONAL  UNITS 


Table  3  -  FUNCTIONAL  UNITS 


ISO/IEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Kernel 

M 

M 

2 

Presentation  Context  Management 

O 

3 

Presentation  Context  Restoration 

c 

B.1.5.  PRESENTATION  PDU  USAGE  BY  PROFILE 


Table  4  KERNEL  PDU  USAGE  BY  PROFILE 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

CONNECT 

PRESENTATION  (CP) 

C/C 

C101 
/M 

C101 
/M 

C101 
/M 

C101 

/M 

C101 
/M 

C101 

/M 

2 

CONNECT 

PRESENTATION  ACCEPT 
(CPA) 

C/C 

C102 
/C101 

CI  02 
/C101 

CI  02 
/C101 

CI  02 
/CI  01 

CI  02 
/C101 

CI  02 
/CI  01 

3 

CONNECT 

PRESENTATION  REJECT 
(CPR) 

C/C 

M 

/C101 

M 

/C101 

M 

/CI  01 

M 

/CI  01 

M 

/CI  01 

M 

/CI  01 

4 

ABNORMAL  RELEASE 
PROVIDER  (ARP) 

M 

M 

M 

M 

M 

M 

M 

5 

ABNORMAL  RELEASE 
USER  (ARU) 

M 

M 

M 

M 

M 

M 

M 

6 

PRESENTATION  DATA 
(TD) 

M 

M 

M 

M 

M 

M 

M 

102.     If  capable  of  accepting  an  AARQ  APDU  then  M,  else  NA. 
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B.1.6.  PRESENTATION  CONTEXT  MANAGEMENT  PDU  USAGE  BY 
PROFILE 


Table  5  PRESENTATION  CONTEXT  MANAGEMENT  PDU  USAGE  BY  PROFILE 


ITEM# 

PROTOCOL  DATA  UNITS 

ISO/I  EC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

ALTER  CONTEXT  (AC) 

O/M 

* 

2 

ALTER  CONTEXT  ACKNOWLEDGE 
JACA) 

M 

* 

* 

B.1.7.  OTHER  PRESENTATION  PDU  USAGE  BY  PROFILE 
Table  6  OTHER  PRESENTATION  PDU  USAGE  BY  PROFILE 


ITEM* 

PROTOCOL  DATA  UNITS 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

PRESENTATION  TYPED  DATA 
(TTD) 

M 

* 

M 

M 

* 

M 

M 

2 

EXPEDITED  DATA  (TE) 

O/M 

* 

3 

CAPABILPTY  DATA  (TC) 

O/M 

• 

NA 

NA 

* 

NA 

NA 

4 

CAPABILITY  DATA 
ACKNOWLEDGE  (TCC) 

O/M 

• 

NA 

NA 

NA 

NA 

5 

RESYNCHRONIZE  (RS) 

O/M 

M 

M 

M 

M 

6 

RESYNCHRONIZE 
ACKNOWLEDGE  (RSA) 

O/M 

M 

M 

• 

M 

M 

B.I. 8.  PRESENTATION  CONTEXT  RESTORATION  FUNCTIONAL  UNIT 


No  additional  PPDUs. 
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B.2.  SUPPORTED  PARAMETERS 

B.2.1.  CONNECT  PRESENTATION  (CP)  PPDU 


Table  7  -  CONNECT  PRESENTATION  (CP)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

1 

Callinq  Presentation  Selector 

O/M 

M 

2 

Called  Presentation  Selector 

O/M 

M 

3 

Mode  Selector 

M 

M 

Normal 

4 

Presentation  Context  Definition  List 

O/M 

M 

5 

Default  Context  Name 

O/M 

C103 

6 

Protocol  Version 

O/M 

M 

7 

Presentation  Requirements 

O/M 

1 

8 

User  Session  Requirements 

O/M 

C104 

1 

9 

User  Data 

O/M 

M 

103.  If  the  Expedited  Data  FU  is  supported  then  M,  else  I. 

104.  If  the  Context  Management  FU  is  supported  then  M,  else  I. 
NOTES 


1 .  TP  does  not  use  this  parameter,  however  a  U-ASE  is  not  prohibited  from  using  it,  subject  to 
the  restrictions  imposed  by  TP  on  the  use  of  Session  Functional  Units. 

B.2.2.  CONNECT  PRESENTATION  ACCEPT  (CPA)  PPDU 


Table  8  -  CONNECT  PRESENTATION  ACCEPT  (CPA)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

Responding  Presentation  Selector 

O/M 

M 

2 

Mode  Selector 

M 

M 

Normal 

3 

Presentation  Context  Definition  Result 
List 

O/M 

M 

4 

Protocol  Version 

O/M 

M 

5 

Presentation  Requirements 

O/M 

* 

1 

6 

User  Session  Requirements 

O/M 

C104 

1 

7 

User  Data 

O/M 

M 

NOTES 


1 .  TP  does  not  use  this  parameter,  however  a  U-ASE  is  not  prohibited  from  using  it,  subject  to 
restrictions  imposed  by  TP  on  the  use  of  Sesison  Functional  Units. 
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B.2.3.  CONNECT  PRESENTATION  REJECT  (CPR)  PPDU 
Table  9  -  CONNECT  PRESENTATION  REJECT  (CPR)  PPDU 


ISO/IEC  8823-2 

P 

ROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA/  ALLOWED 

NOTES 

1 

Responding  Presentation  Selector 

O/M 

M 

2 

Presentation  Context  Definition  Result 
List 

O/M 

M 

3 

Protocol  Version 

O/M 

M 

4 

Default  Context  Result 

O/M 

CI  05 

5 

Provider  Reason 

O/M 

M 

1 

6 

User  Data 

O/M 

M 

105.     If  capable  of  proposing  Default  Context  then  M,  else  I. 
NOTES 

1 .   For  enhanced  Interoperability  it  is  recommended  that  appropriate  provider  reason  values  be 
sent  with  all  CPR  PPDUs. 

B.2.4.  ABNORMAL  RELEASE  USER  (ARU)  PPDU 

Table  10  -  ABNORMAL  RELEASE  USER  (ARU)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

O/M 

M 

2 

User  Data 

O/M 

M 

B.2.5.  ABNORMAL  RELEASE  PROVIDER  (ARP)  PPDU 

Table  11  -  ABNORMAL  RELEASE  PROVIDER  (ARP)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

JIUV  ALLOWED 

NOTES 

1 

Abort  Reason 

O/M 

M 

1 

2 

Event  Identifier 

O/M 

M 

2 

NOTES 


1 .   For  enhanced  interoperability  it  is  recommended  that  appropriate  provider  reason  values  be 
sent  with  all  ARP  PPDUs. 
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2.   For  enhanced  Interoperability  it  is  recommended  that  appropriate  event  identifier  values  be 
sent  with  all  ARP  PPDUs. 

B.2.6.  ALTER  CONTEXT  (AC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.7.  ALTER  CONTEXT  ACKNOWLEDGE  (ACA)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.8.  PRESENTATION  DATA  (TD)  PPDU 


Table  12  -  PRESENTATION  DATA  (TD)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES  1 

1 

User-data 

O/M 

M 

B.2.9.  PRESENTATION  TYPED  DATA  (TTD)  PPDU 

Table  13  -  PRESENTATION  TYPED  DATA  (TTD)  PPDU 
This  PPDU  is  not  applicable  to  profiles  1 1  and  1 2. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

O/M 

M 

B.2.1 0.         EXPEDITED  DATA  (TE)  PPDU 

This  PPDU  Is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 
B.2.1 1 .         CAPABILITY  DATA  (TC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  Is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  11  and  12  However  its  use  by  a  U-ASE  in  profiles  21,22,31  and  32  is  prohibited. 

B.2.12.         CAPABILITY  DATA  ACKNOWLEDGE  (TCC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  1 1  and  12  However  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited. 
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B.2.13.         RESYNCHRONIZE  (RS)  PPDU 

Table  14-  RESYNCHRONIZE  (RS)  PPDU 
This  PPDU  is  not  applicable  to  profiles  1 1  and  1 2. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

G/C 

C104 

2 

User-data 

0/M 

M 

B.2.14.         RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 
Table  15  -  RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 
This  PPDU  is  not  applicable  to  profiles  11  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTE 

1 

Presentation  Context  Identifier  List 

O/M 

01 04 

2 

User-data 

O/M 

M 
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B.2.15.         SESSION  SERVICE  PRIMITIVES  NOT  CARRYING 
PRESENTATION  PCI 


Table  16  SESSION  SERVICE  PRIMITIVES  NOT  CARRYING  PRESENTATION  PCI 


ITEM# 

PRIMITIVES 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

S-REL  r©Q/ind 

0 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

2 

S-REL  rsp/cnf 

0 

•(M) 
/C106 

*(M) 
/CI  06 

•(M) 
/CI  OS 

•(M) 
/CI  06 

/C106 

*(M) 

/CI  06 

3 

S-PT  req'ind 

c 

M 

M 

M 

M 

4 

S-SYNm  req/ind 

0 

M 

M 

M 

M 

5 

S-SYNm  rsp/cnf 

c 

M 

M 

M 

M 

6 

S-SYNM  rec^nd 

0 

7 

S-SYNM  rsp/cnf 

O/M 

8 

S-UER  req/ind 

C 

NA 

NA 

NA 

NA 

NA 

NA 

9 

S-ACTS  req/ind 

0 

NA 

NA 

NA 

NA 

10 

S-ACTR  reqlnd 

C 

NA 

NA 

NA 

NA 

11 

S-ACTE  reqlnd 

0 

NA 

NA 

NA 

NA 

12 

S-ACTE  rsp/cnf 

0 

NA 

NA 

NA 

NA 

106.     If  capable  of  initiating  an  S-REL  req  M  then  else  I. 


29 


Part  1 5  -  Transaction  Processing 
Presentation 


September  1 992  (Stable) 
PDISP  12061-4 


B.3.  SUPPORT  OF  SYNTAXES 

B.3.1.  TRANSFER  SYNTAXES  SUPPORTED 


Table  17  -  TRANSFER  SYNTAXES  SUPPORTED 


SUPPORT 

ITEM# 

TYPE 

DETAIL 

BASE 

P 

1 

Object  Identifier 

jolnt-lso-ccltt  asn1(1)  baslc-encoding(l) 

M 

M 

B.3.2.  ABSTRACT  SYNTAXES  SUPPORTED 


Table  18  -  ABSTRACT  SYNTAXES 


SUPPORT 

NOTES 

ITEM* 

TYPE 

DETAIL 

PROFILE  ID 

BASE 

P 

1 

Object  Identifier 

jolnt-lso-ccltt  assoclation-control(2)  abstract- 
syntax(1 )  apdus(O)  versioni  (1 ) 

O 

2 

Object  Identifier 

joint-lso-ccltt  ccr{7)  abstract-syntax(l)  apdus(O) 
verslon2(2) 

11,12 

0 

1 

1 

21,22,31,32 

O 

M 

3 

Object  Identifier 

jolnt-lso-ccltt  tp(10)  abstract-syntax(l)  apdus{0) 
versioni  (1) 

O 

NOTES 


1 .  This  ISP  specifies  that  a  referencing  specification  shall  not  use  CCR  when  operating  with 
profile  1 1  or  profile  1 2  (in  particular,  refer  to  Parts  5  and  6  clause  7).  However,  when  the 
abstract  syntaxes  are  negotiated  at  the  Presentation  level,  it  is  not  possible  to  identify 
whether  a  protocol  error  shall  be  detected  or  not  (this  can  be  detected  at  the  OSI  TP  level). 
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ANNEX  C:  ACSE  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  use  of  ACSE  services  and  parameters.  The  reader  should  consult  the  upper 
layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies  PDU  parameters 
necessary  for  this  ISP. 

C.1.    SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

Normal  Mode 

O 

M 

2 

X.410-  1984  mode 

O 

NA 

1 

3 

Rules  for  Extensibility 

M 

M 

4 

Supports  Operation  of  Session  Vers.  2 

O 

M 

NOTES 

1 .   Implementations  that  support  X.41 0  mode  shall  respond  to  a  CP  PPDU  proposing  X.41 0-1 984  mode 
with  an  S-U-ABRT;  where  the  user  data  contains  an  Abortlnformation  data  element  (defined  in 
X.410),  which  contains  an  AbortReason  (type  INTEGER)  of  value  4  (protocol  error).  Implementations 
that  do  not  support  X.41 0-1 984  mode  shall  respond  with  either  a  Presentation-Provider  abort  or  a 
Presentation- Provider  Reject. 

C.2.    INITIATOR/RESPONDER  CAPABILITIES 


Table  2  -INITIATOR/RESPONDER  CAPABILITIES 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Association  Initiator 

O 

11,12 

O 

21.22,31,32 

M 

2 

Association  Responder 

O 

11,12 

M 

1 

21 ,22,31 ,32 

M 

NOTES 


1 .  An  implementation  shall  be  capable  of  rejecting  an  AARQ  APDU,  acceptance  of  an  AARQ  APDU  is 
optional. 
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C.3.    FUNCTIONAL  UNITS 


Table  3  -FUNCTIONAL  UNITS 


ISO/IEC  8650-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUV  ALLOWED 

NOTES 

1 

Kernel 

M 

M 

2 

Authentication 

O 

* 

C.4.    ACSE  PDU  USAGE  BY  PROFILE 


Table  4  ACSE  PDU  USAGE  BY  PROFILE 


ITEM* 

Protocol  Data  Units 

ISO/IEC 
8650-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

A-ASSOCIATE-REOUEST 
(AARQ) 

C/C 

C101/M 

M 

M 

C101/M 

M 

M 

1 

2 

A-ASSOCIATE-RESPONSE 
(AARE) 

G/C 

M/C101 

M 

M 

M/C101 

M 

M 

1 

3 

A-RELEASE-REOUEST 
(RLRQ) 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

cm 

4 

A-RELEASE-RESPONSE 
(RLRE) 

WC 

M/C102 

M/C102 

M/C102 

1^0102 

M/C102 

M/C102 

5 

A-ABORT  (ABRT) 

C/C 

M 

M 

M 

M 

M 

M 

101 .  If  capable  of  initiating  an  Association  then  M,  else  I. 

102.  If  capable  of  initiating  A-RELEASE  then  M,  else  I. 
NOTES 

1 .   All  implementations,  including  initiator  only  ones,  shall  have  the  capability  to  receive  an  AARQ  APDU 
and  rejecting  it  with  an  AARE  APDU. 
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C.5.    A-ASSOCIATE-REQUEST  (AARQ) 


Table  5  -  A-ASSOCIATE-REQUEST  (AARQ) 


ISO/I  EC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L;V  ALLOWED 

NOTES 

Protocol  Vsrsion 

C/M 

M 

2 

Application  Context  Name 

M 

M 

3 

Calling  AP  Title 

O/M 

11 ,12 

O/f^ 

1 

21 ,31 ,22,32 

M 

See  Table  10 

1 

4 

walling  MC  \J\Ja\\\\vT 

V^/lVI 

O/M 

See  Table  1 0See  Table 

I 

21 ,31 ,22,32 

1  u 

1 

5 

Calling  AP  Invocation  Identifier 

O/M 

1 1 ,12 

O/M 

1 

21,31,22,32 

O/M 

1,2 

o 

Calling  AE  Invocation  Identifier 

O/M 

11,12 

O/M 

1 

21,31,22,32 

O/M 

1,2 

7 

Called  AP  Title 

O/M 

O/M 

See  Table  1 0 

8 

Called  AE  Qualifier 

O/M 

O/M 

See  Table  10 

Q 

Called  AP  Invocation  Identifier 

O/M 

11,12 

O/M 

1,3 

21,31,22,32 

O/M 

1,3 

10 

Called  AE  Invocation  Identifier 

O/M 

11.12 

O/MO/M 

1,3 

21,31.22.32 

1,3 

11 

Implementattion  information 

C/M 

1 

12 

Requester  ACSE  Requirements 

C/M 

13 

N^echanlsm  Name 

OM 

14 

Calling  Authentication  Value 

C/M 

15 

User  Information 

O/M 

M 

NOTES 


1 .  For  implementations  using  association  pools,  these  parameters  are  recommended  in  order  to  re-use 
associations. 

2.  If  this  parameter  is  received,  then  it  is  recommended  to  be  logged  and  used  for  the  reestablishment 
of  the  association  during  transaction  recovery. 

3.  If  this  parameter  is  sent,  then  it  is  recommended  to  be  logged  and  used  for  the  reestablishment  of  the 
association  during  transaction  recovery. 
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C.6.    A-ASSOCIATE-RESPONSE  (AARE) 


Table  6  -  A-ASSOCIATE-RESPONSE  (AARE) 


ISO/I  EC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LTV  ALLOWED 

NOTES 

1 

Protocol  Version 

C/M 

M 

2 

Application  Context  Name 

M 

M 

3 

Responding  AP  Title 

O/M 

11,12 

O/M 

See  Table  10 

1 

21,31,22,32 

M 

See  Table  1 0 

1 

4 

ResporKJing  AE  Qualifier 

O/M 

11,12 

O/M 

See  Table  1 0 

1 

21,31,22,32 

M 

See  Table  1 0 

1 

5 

Responding  AP  Invocation  Identifier 

O/M 

11,12 

O/M 

21,31,22,32 

O/M 

2 

6 

Responding  AE  Invocation  identifier 

O/M 

11,12 

O/M 

21,31,22,32 

O/M 

2 

7 

Result 

M 

M 

8 

Result  Source  -  Diagnostic 

M 

M 

1  - 10 

C 

11-14 

9 

Implementation  Information 

O/M 

1 

10 

Requester  ACSE  Requirements 

C/M 

11 

Mechanism  Name 

C/M 

12 

Calling  Authentication  Value 

C/M 

13 

User  Information 

O/M 

M 

NOTES 


1 .  This  parameter  shall  be  present  on  an  AARE  APDU  if  the  called  parameter  was  present  in  the  AARQ 
APDU  and  the  responding  parameter  is  different  from  the  called  parameter. 

2.  If  this  parameter  is  received,  then  it  is  recommended  to  be  logged  and  used  for  re-establishment  of 
the  association  during  transaction  recovery. 


C.7     A-RELEASE-REQUEST  (RLRQ) 

Table  7  -  A-RELEASE-REQUEST  (RLRQ) 


ISO/I  EC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VLN  ALLOWED 

NOTES 

1 

Reason 

O/M 

1 

2 

User  information 

O/M 

1 
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B.2.8.  PRESENTATION  DATA  (TD)  PPDU 


Table  12  -  PRESENTATION  DATA  (TD)  PPDU 


ISO/IEC  8823-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

User-data 

O/M 

M 

B.2.9.  PRESENTATION  TYPED  DATA  (TTD)  PPDU 

Table  13  -  PRESENTATION  TYPED  DATA  (TTD)  PPDU 
This  PPDU  Is  not  applicable  to  profiles  1 1  and  1 2. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

User-data 

O/M 

M 

B.2.10.         EXPEDITED  DATA  (TE)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP. 

B.2.1 1 .         CAPABILITY  DATA  (TC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  1 1  and  12  However  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited. 

B.2.1 2.         CAPABILITY  DATA  ACKNOWLEDGE  (TCC)  PPDU 

This  PPDU  is  not  used  by  TP.  Its  use  by  a  U-ASE  is  not  specified  by  this  ISP.  It  can  be  used  by 
Profiles  1 1  and  12  However  its  use  by  a  U-ASE  in  profiles  21 ,22,31  and  32  is  prohibited. 
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B.2.13.         RESYNCHRONIZE  (RS)  PPDU 

Table  14-  RESYNCHRONIZE  (RS)  PPDU 
This  PPDU  is  not  applicable  to  profiles  1 1  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Presentation  Context  Identifier  List 

c/c 

CI  04 

2 

User-data 

O/M 

M 

B.2.14.         RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 
Table  15  -  RESYNCHRONIZE  ACKNOWLEDGE  (RSA)  PPDU 
This  PPDU  is  not  applicable  to  profiles  1 1  and  12. 


BASE  STANDARD  ISO  8823 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTE  i 

1 

Presentation  Context  Identifier  List 

O/M 

C104 

2 

User-data 

O/M 

M 
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B.2.15.         SESSION  SERVICE  PRIMITIVES  NOT  CARRYING 
PRESENTATION  PCI 

Table  16  SESSION  SERVICE  PRIMITIVES  NOT  CARRYING  PRESENTATION  PCI 


ITEM# 

PRIMITIVES 

ISO/IEC 
8823-2 

PROFILES 

11 

21 

31 

12 

22 

32 

NOTES 

1 

S-REL  req/Ind 

C 

D/M 

\Ji  Ivl 

O/M 

V-VIVl 

D/M 

O/M 

2 

S-REL  rsp/cnf 

C 

'M 

/CI  06 

*M 

/CI  06 

*M 

/C106 

*M 

/CI  06 

*M 

/C106 

*M 

/C106 

3 

S-PT  req/Ind 

C 

• 

M 

M 

* 

M 

M 

4 

StSYNiti  req/Ind 

C 

* 

M 

M 

M 

M 

5 

S-SYNm  rsp/cnf 

C 

M 

M 

* 

M 

M 

6 

S-SYNM  req/Ind 

C 

• 

* 

* 

* 

* 

* 

7 

S-SYNM  rsp/cnf 

O/M 

* 

* 

• 

* 

8 

S-UER  req/Ind 

C 

NA 

NA 

NA 

NA 

NA 

NA 

9 

S-ACTS  req/Ind 

C 

NA 

NA 

NA 

NA 

10 

S-ACTR  req/Ind 

C 

NA 

NA 

* 

NA 

NA 

11 

S-ACTE  req/Ind 

C 

• 

NA 

NA 

* 

NA 

NA 

12 

S-ACTE  rsp/cnf 

C 

* 

NA 

NA 

NA 

NA 

106.     If  capable  of  initiating  an  S-REL  req  M  then  else  I. 
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B.3.  SUPPORT  OF  SYNTAX'S 

B.3.1.  TRANSFER  SYNTAX'S  SUPPORTED 

Table  17  -  TRANSFER  SYNTAX'S  SUPPORTED 


SUPPORT 

ITEM# 

TYPE 

DETAIL 

BASE 

P 

1 

Object  Identifier 

|olnt-lso-ccltt  asn1  (1 )  basic-encodlng(1 ) 

M 

M 

B.3.2.  ABSTRACT  SYNTAX'S  SUPPORTED 

Table  18  -  ABSTRACT  SYNTAX'S 


SUPPORT 

ITEM# 

TYPE 

DETAIL 

PROFILE  ID 

BASE 

P 

1 

Object  Identifier 

|oint-iso-ccltt  associatlon-controi(2)  abstract- 
syntax(1)  apdus(O)  versioni  (1) 

O 

M 

2 

Object  Identifier 

|oint-iso-ccitt  ccr(7)  abstract-syntax(l)  apdus(O) 
version2(2) 

11.12 

O 

NA 

21 ,22,31 ,32 

O 

M 

3 

Object  Identifier 

(oint-lso-ccitt  tp{10)  abstract-syntax(l)  apdus(O) 
versioni  (1) 

O 

M 
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ANNEX  C:  ACSE  PROTOCOL  PDUs  (Normative) 


This  subclause  details  TP's  use  of  ACSE  services  and  parameters.  The  reader  should  consult 
the  upper  layer  agreements  for  a  detailed  discussion  of  these  services.  This  ISP  only  specifies 
PDU  parameters  necessary  for  this  ISP. 

C.1.    SUPPORTED  FUNCTIONS 


Table  1  -  SUPPORTED  FUNCTIONS 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Normal  Mode 

O 

M 

2 

X.410- 1984  mode 

O 

NA 

1 

3 

Rules  for  Extensibility 

M 

M 

4 

Supports  Operation  of  Session  Vers.  2 

O 

M 

NOTES 

1 .  The  posssibility  of  the  TPPM  generating  an  ACSE-user  Abort  in  response  to  a  proposed 
X.41 0-mode  connection  is  not  possible.  Because  no  Presentation  Contexts  are  proposed 
with  the  X.41 0-mode  connection,  it  is  not  possible  to  build  an  ABRT  APDU  (at  the  very  least 
the  PCI  for  ACSE  is  missing).  For  implementations  that  support  X.41 0-mode  only,  we 
propose  responding  to  a  CP  PPDU  proposing  X.41 0-1 984  mode  with  an  S-U-ABRT  setting 
the  user  data  to  Abortlnformation  data  element  (as  defined  in  X.410),  which  contains  the 
AbortReason  (INTEGER)  of  value  4  (protocolError).  For  implementations  that  do  not  support 
X.41 0-1 984  mode,  it  is  sufficient  to  respond  with  either  a  Presentation-Provider  Abort  or  a 
Presentation- Provider  Refuse. 
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C.2.    INITIATOR/RESPONDER  CAPABILITIES 

Table  2  -INITIATOR/RESPONDER  CAPABILITIES 


ISO/I  EC  8650-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Association  Initiator 

O 

11,12 

O 

21,22,31,32 

M 

2 

Association  Responder 

O 

11,12 

M 

1 

21,22,31,32 

M 

NOTES 


1 .   An  implementation  shall  be  capable  of  rejecting  an  AARQ  APDU,  acceptance  of  an  AARQ 
APDU  is  optional. 
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C.3.    FUNCTIONAL  UNITS 

Table  3  -FUNCTIONAL  UNITS 


ISO/I  EC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Kernel 

M 

M 

2 

Authentication 

O 

* 

C.4.    ACSE  PDU  USAGE  BY  PROFILE 

Table  4  ACSE  PDU  USAGE  BY  PROFILE 


ITEM# 

Protocol  Data  Units 

ISO/I  EC 
8650-2 

Profiles 

11 

21 

31 

12 

22 

32 

Notes 

1 

A-ASSOCIATE-REOUEST 
(AARO) 

c/c 

C101/M 

M 

M 

C101/M 

M 

M 

1 

2 

A-ASSOCIATE-RESPONSE 
(AARE) 

c/c 

M/C101 

M 

M 

M/C101 

M 

M 

1 

3 

A-RELEASE-REOUEST 
(RLRQ) 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

O/M 

4 

A-RELEASE-RESPONSE 
(RLRE) 

M/C 

M/C102 

M/C102 

M/C102 

M/C102 

M/C102 

M/C102 

5 

A-ABORT  (ABRT) 

C/C 

M 

M 

M 

M 

M 

M 

101 .  If  capable  of  initiating  an  Association  then  M,  else  I. 

102.  If  capable  of  initiating  A-RELEASE  then  M,  else  I. 
NOTES 


1 .  All  implementations,  including  initiator  only  ones,  shall  have  the  capability  to  receive  an 
AARQ  APDU  and  rejecting  it  with  an  AARE  APDU. 


ill 
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C.5.    A-ASSOCIATE-REQUEST  (AARQ) 

Table  5  -  A-ASSOCIATE-REQUEST  (AARQ) 


ISO/SEC  8650-2 

PROFILE 

ITEM# 

□  ADA  HJICTCD 

O  1  A  1 UO 

DDf^CII  c  in 
nn\JrlLc  lU 

CTATI  IC 
O 1 A  1 Uo 

T/l  A/  Al  1  /^uicn 

n\J  \  CO  || 

1 

Protocol  Version 

O/IVl 

M 

2 

Application  Context  Name 

M 

hjl 
IVl 

3 

Calllna  AP  Title 

V^CIIIII  IM              1  lift? 

O/M 

11,12 

O/M 

01  Q1  OO  'iO 

IVl 

4 

O/M 

1112 

O/M 

dl  ,■31  ,d.£.,i£. 

M 

5 

Calling  AP  Invocation  Identifier 

O/M 

1  1  ,12 

21,31,22,32 

O/M 

1,2 

6 

Calling  AE  Invocation  Identifier 

O/M 

1 1 ,12 

* 

21,31,22,32 

O/M 

1,2  ' 

7 

uaiiea  Ar  i  me 

D/M 

vJ/M 

8 

Called  AE  Qualifier 

O/M 

O/M 

9 

Called  AP  Invocation  Identifier 

O/M 

11,12 

* 

1.2 

21,31,22,32 

M 

1,2 

1 

10 

Called  AE  Invocation  Identifier 

O/M 

11,12 

1,2 

21,31,22,32 

M 

1.2 

11 

Implementattion  Information 

C/M 

1 

12 

Requester  ACSE  Requirements 

C/M 

13 

K^echanism  Name 

C/M 

14 

Calling  Authentication  Value 

C/M 

* 

15 

User  Information 

O/M 

M 

NOTES 


1 .  For  implementations  using  association  pools,  these  parameters  are  recommended  in  order  to 
re-use  associations. 

2.  Responder  must  log  calling  Invocation  identifiers  for  recovery  if  they  are  provided  by  the 
initiator.  The  capability  to  exchange  called  Invocation  identifiers  shall  be  implemented  so  that 
associations  may  re-establish  the  same  AE-lnvocation  during  recovery. 


36 


Part  15  -  Transaction  Processing 
ACSE 


June  1992  (Stable) 
pDIsp  xxxx-4 


Temporary  Note:  The  ACSE  recovery  issue  has  raised  2  questions:  1 .  Items  9  &  10  should 
they  be  marked  M  or  O/M  for  the  commitment  profiles.  2.  Should  profiles  1 1  and  1 2  be 
marked  the  same  as  the  commitment  profiles.  Also,  Note  2  is  an  issue  -  the  resolution  of  the 
ACSE  recovery  issue  will  resolve  it. 

C.6.    A-ASSOCIATE-RESPONSE  (AARE) 


Table  6  -  A-ASSOCIATE-RESPONSE  (AARE) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Protocol  Version 

C/M 

M 

2 

Application  Context  Name 

M 

M 

3 

Responding  AP  Title 

O/M 

11,12 

O/M 

1 

21,31,22,32 

M 

1 

4 

Responding  AE  Qualifier 

O/M 

11,12 

O/M 

1 

21 ,31 ,22,32 

M 

1 

5 

Responding  AP  Invocation  Identifier 

O/M 

O/M 

2 

6 

Responding  AE  Invocation  Identifier 

O/M 

O/M 

2 

7 

Result 

M 

M 

8 

Result  Source  -  Diagnostic 

M 

M 

1  - 10 

c 

* 

11  - 14 

9 

Implementation  Information 

O/M 

1 

10 

Requester  ACSE  Requirements 

C/M 

* 

11 

f^echanlsm  Name 

C/M 

* 

12 

Calling  Autlientication  Value 

C/M 

♦ 

13 

User  Information 

O/M 

M 

NOTES 


1 .  This  parameter  shall  be  present  on  an  AARE  APDU  if  the  called  parameter  was  present  in 
the  AARQ  APDU  and  the  responding  parameter  is  different  from  the  called  parameter. 

2.  If  this  parameter  is  received,  then  it  shall  be  logged  and  used  for  re-establishment  of  the 
association  during  recovery. 
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Temporary  Note:  The  ACSE  recovery  issue  has  raised  2  questions:  1 .  Items  5  &  6  should 
they  be  marked  M  or  O/M.  2.  Should  the  commitment  and  non-commitment  profiles  be 
marked  the  same.  Also,  Note  2  is  an  Issue  -  the  resolution  of  the  ACSE  recovery  issue  will 
resolve  it. 


C.7     A-RELEASE-REQUEST  (RLRQ) 

Table  7  -  A-RELEASE-REQUEST  (RLRQ) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Reason 

O/M 

1 

2 

User  information 

O/M 

1 

C.8.    A-RELEASE-RESPONSE  (RLRE) 

Table  8  -  A-RELEASE-RESPONSE  (RLRE) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

J/yy  ALLOWED 

NOTES 

1 

Reason 

O/M 

1 

2 

User  information 

O/M 

i 

C.9.    A-ABORT  (ABRT) 

Table  9  -  A-ABORT  (ABRT) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/L/V  ALLOWED 

NOTES 

1 

Abort  Source 

M 

M 

2 

Abort  Diagnostic 

c 

3 

User  Information 

O/M 

M 
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C.10.  AE  TITLE  NAME  FORMS 

Table  10  -  AE  TITLE  NAME  FORMS 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

SYNTAX  FORM 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Form  1  (Directory  Name) 

O/M 

O/M 

2 

Form  2  (Object  ID) 

O/M 

M 

C.11.  AUTHENTICATION  VALUE  FORM 

Table  11  -  AUTHENTICATION  VALUE  FORM 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/UV  ALLOWED 

NOTES 

1 

Graphic  String 

c/c 

2 

Bit  String 

c/c 

3 

External 

c/c 

* 

4 

Any  Defined  By 

c/c 

• 
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C.8.    A-RELEASE-RESPONSE  (RLRE) 

Table  8  -  A-RELEASE-RESPONSE  (RLRE) 


ISO/I  EC  8650-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

T/LA^  ALLOWED 

NOTES 

1 

Reason 

O/M 

1 

2 

User  Information 

0/M 

1 

C.9.    A-ABORT  (ABRT) 

Table  9  -  A-ABORT  (ABRT) 


ISO/IEC  8650-2 

PROFILE 

ITEM# 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

1 

Abort  Source 

M 

M 

2 

Abort  Diagnostic 

0 

• 

3 

User  Information 

O/M 

M 
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C.10.  AE  TITLE  NAME  FORMS 

Table  10  -  AE  TITLE  NAME  FORMS 


ISO/I  EC  8650-2 

PROFILE 

ITEM# 

SYNTAX  FORM 

STATUS 

PROFILE  ID 

STATUS 

VUW  ALLOWED 

NOTES 

1 

Form  1  (Directory  Name) 

O/M 

O/M 

1  ..  1024  octets 

1 

2 

Form  2  iObject  ID) 

O/M 

M 

1  ..  64  octets 

1 

NOTES 


1 .  The  limits  specified  apply  to  the  AE-Title  which  is  the  combination  of  the  AP-Title  and  AE-Qualifier. 
They  are  specified  in  line  with  the  limits  given  in  Part  3  on  the  Atomic-Action  Identifier  and  the  Branch 
Identifier. 

C.11.  AUTHENTICATION  VALUE  FORM 

Table  11  -  AUTHENTICATION  VALUE  FORM 


ISO/IEC  8650-2 

PROFILE 

ITEM* 

PARAMETER 

STATUS 

PROFILE  ID 

STATUS 

VLN  ALLOWED 

NOTES 

1 

Graphic  String 

C/C 

2 

Bit  String 

C/C 

3 

External 

C/C 

4 

Any  Defined  By 

C/C 
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Introduction 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fomi  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  In 
Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-5:  OSI  Distributed  Transaction  Processing. 

Part  5:  APPLICATION  SUPPORTED  TRANSACTIONS  -  POLARIZED  CONTROL 
(ATP11) 


1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Application  Supported  Transaction  while  the 
application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP1 1  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Application  Supported  Distributed  Transactions,  where  the  applications 
take  responsibility  for  ensuring  that  transaction  semantics  are  maintained,  and  for  restoring  consistency 
after  any  failure.  The  dialogue  between  the  applications  is  subject  to  strict  tum  control.  The  handshake 
fadlity  is  available. 


An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  identified  in  the  table  hereafter: 


5. 


USE  OF  FUNCTIONAL  UNITS 


DIALOGUE 

POLARIZED  CONTROL 
HANDSHAKE 


mandatory 
mandatory 
mandatory 


H  conforms  to  the  Application  Transactions  conformance  class  defined  in  ISO  1 0026-3. 
6.  SCENARIO 


The  applicability  of  the  ATP1 1  profile  is  illustrated  by  the  figure  hereafter: 
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7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below.  The  use  of 
ISO/IEC  9804/9805  (CCR)  by  a  referencing  specification  is  forbidden  and  is  a  protocol  error. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  ^  (ACSE) 

Presentation  Layer 

ISO  8825:1 990  (BER  ASN.1 ) 
ISO  8823:1 988(Presentation) 

Session  Layer 

ISO  83273 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  ACSE,  Presentation  and  Session  PDUs  for  ATP1 1  is  as  described  in  Parts 
1 ,2  and  4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 
ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 


^To  be  published 
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Transaction  Processing  (Brussels  -  June  23-26,  1 992).  Its  content  is  considered  by  the  three  experts 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OS!) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  fonri  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OS  I  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Part  6:  APPLICATION  SUPPORTED  TRANSACTIONS  -  SHARED  CONTROL 
(ATP12) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Application  Supported  Transaction  while  the 
application  is  using  the  Shared  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP12  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Application  Supported  Distributed  Transactions,  where  the  applications 
take  responsibility  for  ensuring  that  transaction  semantics  are  maintained,  and  for  restoring  consistency 
after  any  failure.  The  dialogue  between  the  applications  is  not  subject  to  turn  control.  The  support  of  the 
handshake  facility  is  optional. 


5. 


USE  OF  FUNCTIONAL  UNITS 


An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 


mandatory 
mandatory 
optional 


It  conforms  to  the  Application  Transactions  conformance  class  defined  in  ISO  10026-3. 
6.  SCENARIO 


The  applicability  of  the  ATP12  profile  is  illustrated  by  the  figure  hereafter: 
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7.       USAGE  OF  UNDERLYING  STANDARDS 


This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below.  The  use  of 
ISO/IEC  9804/9805  (CCR)  by  a  referencing  specification  is  forbidden  and  is  a  protocol  error. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  (ACSE) 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 

Session  Layer 

ISO  83274 

8.       DETAILED  DESCRIPTION 


The  support  of  the  OSI  TP,  ACSE,  Presentation  and  Session  PDUs  for  ATP1 2  is  as  described  in  Parts 
1 ,2  and  4  of  this  standard. 

9.  CONFORMANCE 


;  Confomiance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
,  12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
1  Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  1 0026-4  (OSI  TP) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 
I         •       ISO/IEC  8327-2  (Session) 


^To  be  published 


I 


I 

\ 


■I 


i 


Part  1 5  -  Transaction  Processing 
Profile  ATP21 


September  1 992  (Stable) 
PDISP  12061-7 


TITLE:  WORKING  DOCUMENT  FOR 


Information  Technology  -  Open  Systems  Interconnection  -  International  Standardized  Profile  12061-7: 
OSI  TP 


Part  7:  Provider  Supported  Unchained  Transactions  -  Polarized  Control  (ATP21) 
SOURCE:  Joint  AOW  /  EWOS  /  OIW  on  Transaction  Processing 


DATE:  September  25,  1992 


STATUS:  This  document  has  been  produced  during  the  second  AOW/EWOS/OIW  joint  meeting  on 
Transaction  Processing  (Brussels  -  June  23-26,  1992).  Its  content  is  considered  by  the  three  experts 
groups  as  harmonized,  and  all  issues  have  been  resolved.  The  OIW,  formally,  considers  this  document 
to  be  harmonized  with  all  issues  resolved  and  will  submit  it  to  ISO/IEC  JTC1/SGFS  when  the  document  is 
approved  by  the  other  workshop  plenaries.  The  final  document  is  expected  to  be  submitted  to  ISO/IEC 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  10  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Part  7:  PROVIDER  SUPPORTED  UNCHAINED  TRANSACTIONS  -  POLARIZED 
CONTROL  (ATP21) 

1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  unchained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP21  Is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Unchained  sequence  of  Provider 
Supported  Transaction  Branches.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control. 
The  handshake  facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 

mandatory 

POLARIZED  CONTROL 

mandatory 

HANDSHAKE 

mandatory 

COMMIT 

mandatory 

UNCHAINED  TRANSACTIONS 

mandatory 

RECOVERY 

mandatory 

!  It  conforms  to  the  Unchained  Provider  Supported  Transaction  Branches  conformance  class  defined  in 
ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP21  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP21 
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7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988 (Presentation) 
ISO  8823  AM5 

Session  Layer 

ISO  8327^ 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP21  is  as  described  in 
Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISP 
12061-3,  ISO/IEC  ISP  12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 
ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 
ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 


^To  be  published 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Part  8:  PROVIDER  SUPPORTED  UNCHAINED  TRANSACTIONS  -  SHARED 
CONTROL  (ATP22) 


1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  Unchained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Shared  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP22  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Unchained  sequence  of  Provider 
Supported  Transaction  Branches.  The  dialogue  between  the  applications  is  not  subject  to  turn  control. 
The  support  of  the  handshake  facility  is  optional. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 

mandatory 

SHARED  CO^^^ROL 

mandatory 

HANDSHAKE 

optional 

COMMIT 

mandatory 

UNCHAINED  TRANSACTION 

mandatory 

RECOVERY 

mandatory 

It  conforms  to  the  Unchained  Provider  Supported  Transactions  Branches  conformance  class  defined  in 
ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP22  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP22 
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7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  I  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1 990  (BER  ASN.1 ) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM5 

Session  Layer 

ISO  8327^ 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP22  is  as  described  in 
Parts  1  -  4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISO/IEC 
ISP  12061-3,  ISP  12061-4  apply  to  this  part. 

For  each  Implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 
ISO/IEC  1 0026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 


®To  be  published 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

c.  of  different  levels  of  complexity, 

d.  of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OS!) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  10. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  1 0. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-9:  OSI  Distributed  Transaction  Processing. 


Part  9:  PROVIDER  SUPPORTED  CHAINED  TRANSACTIONS  -  POLARIZED 
CONTROL  (ATP31) 

1.  SCOPE 

This  Part  of  tfiis  ISP  defines  the  OSI  TP  profile  used  for  chained  sequences  of  Provider  Supported 
Transaction  branches  while  the  application  is  using  the  Polarized  Control  paradigm  for  communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP31  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider  of  the 
OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for  restoring  consistency 
after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Chained  Sequence  of  Provider  Supported 
Transaction  Branches.  The  dialogue  between  the  applications  is  subject  to  strict  turn  control.  The 
handshake  facility  is  available. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


DIALOGUE 

mandatory 

POLARIZED  CONTROL 

mandatory 

HANDSHAKE 

mandatory 

COMMIT 

mandatory 

CHAINED  TRANSACTION 

mandatory 

RECOVERY 

mandatory 

It  conforms  to  the  Chained  Provider  Supported  Transaction  Branches  conformance  class  defined  in 
ISO  10026-3. 
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6.  SCENARIO 

The  applicability  of  the  ATP31  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP31 
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7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM5 

Session  Layer 

ISO  8327^ 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP31  is  as  described  in 
Parts  1  -4  of  this  standard. 

9.  CONFORMANCE 

Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC  ISO/IEC 
ISP  12061-3,  ISP  12061-4  apply  to  this  part. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  1 0026-4  (OSI  TP) 
ISO/IEC  9805-2  (CCR) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 


^To  be  published 
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INTRODUCTION 

The  aim  of  Open  Systems  Interconnection  is  to  allow,  with  a  minimum  of  technical  agreement  outside  the 
interconnection  standards,  the  interconnection  of  computer  systems 

a.  from  different  manufacturers, 

b.  under  different  management, 

0.      of  different  levels  of  complexity, 
d.      of  different  technologies. 

Transaction  Processing  is  concerned  with  identifiable  information  which  can  be  related  as  transactions, 
which  may  involve  two  or  more  Open  Systems.  In  the  framework  of  Open  Systems  Interconnection  (OSI) 
a  transaction  is  defined  as  "a  set  of  related  operations  characterized  by  four  properties:  atomicity, 
consistency,  isolation  and  durability." 

The  definition  highlights  that  a  distributed  transaction  is  more  than  a  simple  exchange  of  messages,  but 
that  the  exchanges  form  a  protected  indivisible  set. 


This  multi-part  document  contains  the  complete  specification  of  the  six  profiles  identified  in  M-IT-02  and 
TR  10000. 

Part  1  contains  the  taxonomy  for  the  OSI  TP  profiles. 

Part  2  contains  the  specification  of  the  support  of  OSI  TP  APDUs  for  each  of  the  profiles  specified  in 
Parts  5  to  1 0. 

Part  3  contains  the  specification  of  the  support  of  the  CCR  APDUs  for  each  of  the  profiles  specified  in 
Part  5  to  10. 

Part  4  contains  the  specification  of  the  support  of  ACSE,  Presentation  and  Session  APDUs  for  each  of 
the  profiles  specified  in  Part  5  to  1 0. 

Parts  5  to  1 0  specify  the  six  profiles  which  are  defined,  based  on  the  OSI  TP  standard.  These  six  parts 
make  reference  to  Parts  2  to  4. 
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Information  Technology  -  Open  Systems  Interconnection  -  International 
Standardized  Profiles  12061-10:  OSI  Distributed  Transaction  Processing. 


Part  10:  PROVIDER  SUPPORTED  CHAINED  TRANSACTIONS  -  SHARED 
CONTROL  (ATP32) 


1.  SCOPE 

This  Part  of  this  ISP  defines  the  OSI  TP  profile  used  for  chained  sequences  of  Provider 
Supported  Transaction  branches  while  the  application  is  using  the  Shared  Control  paradigm  for 
communications. 

2.  NORMATIVE  REFERENCES 

The  references  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

3.  DEFINITIONS  AND  ABBREVIATIONS 

The  definitions  and  abbreviations  listed  in  Part  1  of  this  ISP  apply  to  this  Part. 

4.  OVERVIEW 

Profile  ATP32  is  applicable  to  end  systems  concerned  with  operating  in  the  Open  Systems 
Interconnection  (OSI)  environment.  This  profile  specifies  a  combination  of  OSI  standards,  which 
collectively  provide  support  for  Provider  Supported  Distributed  Transactions,  where  the  provider 
of  the  OSI  TP  service  takes  responsibility  for  ensuring  transaction  ACID  properties  and  for 
restoring  consistency  after  any  failure.  Two  applications  operate  on  a  dialogue  in  an  Chained 
sequence  of  Provider  Supported  Transaction  Branches.  The  dialogue  between  the  applications 
is  not  subject  to  turn  control.  The  support  of  the  handshake  facility  Is  optional. 

5.  USE  OF  FUNCTIONAL  UNITS 

An  implementation  of  this  profile  supports  the  OSI  TP  functional  units  as  shown  hereafter: 


It  conforms  to  the  Chained  Provider  Supported  Transaction  Branches  conformance  class  defined 
In  ISO  10026-3. 


DIALOGUE 
SHARED  CONTROL 
HANDSHAKE 
COMMIT 

CHAINED  TRANSACTION 
RECOVERY   


mandatory 
mandatory 
optional 


mandatory 
mandatory 
mandatory 
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6.  SCENARIO 

The  applicability  of  the  ATP32  profile  is  illustrated  by  the  figure  hereafter: 


TP  SYSTEM 

TP  SYSTEM 

ATP32 
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7.       USAGE  OF  UNDERLYING  STANDARDS 

This  profile  specifies  the  required  functions  from  the  supporting  protocol  stacks  shown  below. 


Application  Layer 

ISO  10026-3:1992  (OSI  TP) 
ISO  8650  1  (ACSE) 
ISO  9805:1 990(CCR) 
ISO  9805  AM2 

Presentation  Layer 

ISO  8825:1990  (BER  ASN.1) 
ISO  8823:1 988(Presentation) 
ISO  8823  AM5 

Session  Layer 

ISO  8327^ 
ISO  8327  AM3 

8.  DETAILED  DESCRIPTION 

The  support  of  the  OSI  TP,  CCR,  ACSE,  Presentation  and  Session  PDUs  for  ATP32  is  as 
described  in  Paris  1  -  4  of  this  standard. 

9.  CONFORMANCE 


Conformance  requirements  specified  in  ISO/IEC  ISP  12061-1,  ISO/IEC  ISP  12061-2,  ISO/IEC 
ISO/IEC  ISP  12061-3,  ISP  12061-4  apply  to  this  pari. 

For  each  implementation  claiming  conformance  to  this  part  of  ISO/IEC  12061,  the  following  PICS 
Proformas  shall  be  completed  and  made  available  : 

•  ISO/IEC  10026-4  (OSI  TP) 

•  ISO/IEC  9805-2  (CCR) 

•  ISO/IEC  8650-2  (ACSE) 

•  ISO/IEC  8823-2  (Presentation) 

•  ISO/IEC  8327-2  (Session) 


®To  be  published 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture 
Special  Interest  Group  (ODASIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  No  significant 
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shaded. 
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This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Network  Management  Special  Interest 
Group  (NMSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW).  See  Procedures  Manual 
for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces  the 
previously  existing  chapter  on  this  subject. 

To  highlight  textual  changes  since  the  last  Workshop  output,  additions  to  the  text  in  this  part  are  marked  with 
shading;  deleted  text  is  left  in  but  marked  with  strikeouts. 
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18  Network  Management 


0  Introduction 

Within  the  community  of  OS!  researchers,  users,  and  vendors,  there  is  a  recognized  need  to  address  the 
problems  of  initiating,  terminating,  monitoring,  and  controlling  communication  activities  and  assisting  in  their 
harmonious  operation,  as  well  as  handling  abnormal  conditions.  The  activities  that  address  these  problems 
are  collectively  called  network  management. 

Network  management  can  be  viewed  as  the  set  of  operational  and  administrative  mechanisms  necessary  to: 

a.  bring  up,  enroll,  and/or  alter  network  resources; 

b.  keep  network  resources  operational; 

c.  fine  tune  these  resources  and/or  plan  for  their  expansion; 

d.  manage  the  accounting  of  their  usage; 

e.  manage  their  protection  from  unauthorized  use/tampering. 

As  such,  network  management  is  typically  concerned  with  management  activities  in  at  least  the  following  five 
functional  areas:  configuration  management,  fault  management,  performance  management,  accounting 
management,  and  security  management.  In  order  to  accomplish  these  management  activities,  information 
must  be  exchanged  among  open  systems. 

In  Part  18,  there  are  Implementation  Agreements  (lA's)  for  providing  interoperable  OSI  management 
information  communication  services  among  OSI  systems.  Also  contained  here  are  agreements  on 
management  information.  These  agreements  pertain  to  the  exchange  of  management  information  and 
management  commands  between  open  systems  operating  in  a  multivendor  environment.  For  example,  one 
goal  is  to  ensure  that  a  management  system  built  by  one  vendor  can  manage  objects  built  by  another  vendor. 
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1  Scope 


The  purpose  of  this  Part  (Part  18),  is  to  provide  implementation  agreements  that  will  enable  independent 
vendors  to  supply  customers  with  a  diverse  set  of  networking  products  that  can  be  managed  as  part  of  an 
integrated  environment.  Where  possible,  these  agreements  are  based  up)on  OSI  Systems  Management 
standards. 


Because  of  the  broad  scope  of  the  subject,  and  given  that  OSI  Systems  Management  standards  are  still 
evolving,  it  is  reasonable  to  assume  that  a  comprehensive  set  of  network  management  implementation 
agreements  will  take  a  number  of  years  to  develop.  To  arrive  at  an  initial  set  of  implementation  agreements 
in  a  timely  fashion,  a  phased  approach  has  been  adopted. 

This  phased  work  approach  will  result  in  a  series  of  implementation  agreements  based  on  the  expanding  scope 
of  the  OSI  Systems  Management  standards.  It  is  the  intention  of  the  NMSIG  to  define  the  content  of  each 
phase  as  a  compatible  superset  of  the  previous  Phases  to  ensure  that  Phase  N  products  can  interact  with 
products  based  on  the  implementation  agreements  of  earlier  phases. 


1.1.1       Alignment  With  Evolving  Standards 

In  some  cases,  these  phased  implementation  agreements  may  be  based  on  DIS  standards.  As  the  relevant 
standards  progress  from  DIS  to  IS,  the  agreements  will  be  aligned  in  future  phases. 

When  a  defect  is  found  in  any  of  the  management  related  standards,  the  reported  defect  may  be  technically 
resolved  by  the  appropriate  international  technical  committee  with  likely  approval  by  the  voting  members 
pending  for  several  months.  Since  relevant  defects  can't  be  ignored  in  an  implementation,  these  agreements  j 
will  note  defect  resolutions  which  have  the  tentative  approval  of  the  appropriate  standards  committee.  These 
interim  resolutions  will  be  recorded  in  clause  4. 

Once  a  defect  resolution  has  been  completed  by  the  appropriate  standards  body,  the  agreed  upon  resolution 
will  be  incorporated  into  the  next  phase  of  these  implementors  agreements.  If  appropriate,  a  previous  phase  j 
that  relied  on  an  interim  resolution  will  be  examined  to  determine  whether  errata  should  be  issued  to  bring  the  i 
original  phase  into  line  with  the  final  resolution. 


1.1.2       Definition  Of  Phase  1 

As  a  first  step  in  this  phased  approach,  the  NMSIG  has  targeted  an  initial  set  of  agreements  that  provide  limited 
interoperable  management  in  a  heterogeneous  vendor  environment.  They  are  the  beginning  of  a 
comprehensive  set  of  implementation  agreements  based  on  the  emerging  OSI  Systems  Management 
standards.  Furthermore,  these  initial  agreements  allow  the  community  to  gain  experience  with  OSI 
management  standards  as  they  emerge. 


1.1 


Phased  Approach 


2 


PART  18:  Network  Management 


September  1992  (Stable) 


The  focus  of  the  Phase  1  agreements  is  to  enable  a  nnanaging  process  provided  by  one  vendor  to  interoperate 
with  an  agent  process  provided  by  a  different  vendor  to  perform  limited  management  on  a  set  of  managed 
objects. 

The  scope  of  Phase  1  implementation  agreements  is  the  following: 

Management  Functions: 

Object  Management  Function  [OMF], 

State  Management  Function  [STMF], 

Attributes  For  Representing  Relationships  [ARR], 

Alarm  Reporting  Function  [ARF], 

Event  Report  Management  Function  [ERMF]. 

Management  Information: 

Information  Model,  Naming,  Guidelines  and  Templates  for  Defining  Managed  Objects 
Management  Communication: 

CMIS/P,  Association  Policies,  and  Upper  Layer  Services  Required 
Management  Objects: 

Support  Objects  required  for  the  above. 

Editor's  Note:  [The  relation  of  the  MIL  definitions  in  Annex  A  of  the  Worl<ing  Document  to  Phase 
1  lA's  needs  to  be  clarified.] 

Conformance  Criteria: 

Conformance  Criteria  for  the  above  functionality. 

To  accomplish  these  goals  in  a  timely  fashion,  the  following  simplifying  constraints  have  been  reflected  in  the 
Phase  1  agreements: 

1 .  No  agreements  are  provided  regarding  management  domains; 

2.  These  agreements  require  only  the  following  application  service  elements:  the  Association 
Control  Service  Element  (ACSE),  the  Common  Management  Information  Service  Element 
(CMISE),  Remote  Operations  Service  Element  (ROSE),  and  the  System  Management  Application 
Service  Element  (SMASE); 

3.  These  agreements  do  not  require  implementation  of  services  defined  by  the  Directory  standards; 
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4.   No  agreements  regarding  the  security  of  management  are  provided. 


1.1.3       Future  Phases 

It  is  tlie  intention  of  thie  NMSIG  to  freeze  tlie  content  of  Phase  1  when  these  agreements  are  progressed  to 
Stable  status.  Alignment  changes  required  as  the  standards  progress  from  DIS  to  IS  will  be  made  in  future 
phases. 

As  standards  defining  new  functionality  are  progressed,  the  NMSIG  will  define  future  phases  incorporating  the 
new  functionality  as  a  compatible  superset  of  previous  phases. 


2     Normative  References 

The  following  documents  are  referenced  in  the  statements  of  the  agreements  relating  to  OSI  systems 
management. 

Editor's  Note:  [Items  marked  with  an  asterisl<,  are  ones  which,  while  not  cited  in  the  text  of  this  part 
of  the  lAs,  are  included  here,  nevertheless,  to  indicate  where  useful  background  information 
can  be  found.] 

ISO  8650,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Protocol 
Specification  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8650), 
ISO/IEC  JTC1/SC21  N2327,  21  April  1988. 

ISO  8649,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Service 
Definition  for  the  Association  Control  Service  Element  (Revised  Final  Text  of  DIS  8649), 
ISO/IEC  JTC1  /SC21  N2326,  21  April  1 988. 

ISO/IEC9596/DAD2,  Common  Management  Information  Protocol  Specification:  Addendum 
2  (Add/Remove  Protocol),  ISO/IEC  JTC1/SC21, 1  February  1990. 

ISO/IEC  9595/DAD  2,  Common  Management  Information  Service  Definition:  Addendum  2 
(Add/Remove  Service),  ISO/IEC  JTC1/SC21, 1  February  1990. 

ISO/IEC  DIS  9545,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Application  Layer  Structure,  15  March  1989. 

ISO/IEC  ISP  1 1 183-1,  Information  Technology  -  International  Standardized  Profiles  AOMIn 
OSI  Management  -  Management  Communications  -  Part  1:  Specification  of  ACSE, 
Presentation  and  Session  Protocols  for  the  use  by  ROSE  and  CMISE,  May  1992. 

ISO/IEC  ISP  1 1 183-3,  Information  Technology  -  International  Standardized  Profiles  AOMIn 
OSI  Management  -  Management  Communications  -  Part  3:  CMISE/ROSE  for  A0M1 1  -  Basic 
Management  Communications,  May  1992. 


[ACSEP] 

[ACSESJ* 

[ADDRMVP] 
[ADDRMVS] 
[ALS]* 
[A0M1PT1] 

[A0M1PT3] 
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[A0M1 PT2]  ISO/IEC  ISP  1 1 1 83-2,  Information  Technology  -  International  Standardized  Profiles  AOM 1  n 
OSI  Management  -  Management  Communications  -  Part  2:  CMISE/ROSE  for  A0M12  - 
Enhanced  Management  Communications,  May  1992. 

[A0M21 1  ]  pDISP  1 2060-1 ,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  1 :  A0M21 1  -  General  Management  Capabilities. 
July  1992. 

[AOM212]  pDISP  12060-2,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  2:  AOM212  -  Alarm  Reporting  and  State 
Management  Capabilities,  July  1992. 

[ApM213]  pDISP  12060-3,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  3:  AOM213  -  Alarm  Reporting  Capabilities,  July 
1992. 

[AOM221  ]  pDISP  1 2060-4,  Information  Technology  -  International  Standardized  Profiles  -  A0M2nn  OSI 
Management  -  Management  Functions  -  Part  4:  AOM221  -  General  Event  Report 
Management,  July  1992. 

[AOM231]  pDISP  12060-5,  Information  Technology  -  International  Standardized  Profiles  -  A0M2n  OSI 
Management  -  Management  Functions  -  Part  5:  AOM231  -  General  Log  Control  Profile,  July 
1992. 

[ARF]  ISO/IEC  IS  10164-4,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  4:  Alarm  Reporting  Function,  ISO/IEC  JTC1/SC21  N6359,  August  19, 
1991. 

[ARR]  ISO/IEC  IS  10164-3,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management -Part  3:  Attributes  for  Representing  Relationships,  ISO/IEC  JTC1/SC21  N5186, 
September  1991. 

[ASN1]*  ISO/IEC  8824,  Information  Technology  -  Open  System  Interconnection  -  Specification  of 

Abstract  Syntax  Notation  One  (ASN.I),  ISO/IEC  JTC1/SC21  N4720,  30  April  1990. 

[BER]  ISO/IEC  8825,  Information  Technology  -  Open  Systems  Interconnection  -  Specification  of 

Basic  Encoding  Rulesfor  Abstract  Syntax  Notation  One  (ASN.I ),  ISO/IEC  JTC1  /SC21  N4721 , 
30  April  1990. 

[CANGETP]  ISO/IEC9596/DAD 1 ,  Common  Management  Information  Protocol  Specification:  Addendum 
1  (CancelGet  Protocol),  ISO/IEC  JTC1/SC21, 1  February  1990. 

[CANGETS]  ISO/IEC  9595/DAD  1 ,  Common  Management  Information  Service  Definition:  Addendum  1 
(CancelGet  Service),  ISO/IEC  JTC1  /SC21 . 1  February  1 990. 
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[CMIP]  ISO/IEC  9596-1,  Information  Technology  -  Open  Systems  Interconnection  -  Common 

Management  Information  Protocol  Specification  -  Part  1 :  Specification,  24  November  1990. 

[CMIS]  ISO/IEC  9595,  Information  Technology  -   Open  Systems  Interconnection  -  Common 

Management  Information  Service  Definition,  Common  Management  Information  Service,  24 
November  1990. 

[DIR]*  ISO  9594  -  Information  Processing  Systems  -  Open  Systems  Interconnection  -  The  Directory, 

1988. 

[DMI]  ISO/IEC  IS  101 65-2,  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of 

Management  Information  -  Part  2:  Definition  of  Management  Information,  ISO/IEC 
JTC1/SC21  N6363,  August  1991. 

[ENSCON]*  Forum  025,  The  "Ensemble"  Concepts  and  Format,  Issue  1 .0,  Network  Management  Forum, 
July  1992. 

[ERMF]  ISO/IEC  IS  10164-5,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  5:  Event  Report  Management  Function,  ISO/IEC  JTC1/SC21  N6360, 
August  1991. 

[FRMWK]*  ISO  7498-4,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Reference  Model  -  Part  4:  Management  Framework,  1989. 

[GDMO]  ISO/IEC  IS  10165-4,  Information  Technology  -  Open  Systems  Interconnection  -  Structure  of 

Management  Information  -  Part  4:  Guidelines  for  the  Definition  of  Managed  Objects,  ISO/IEC 
JTC1/SC21  N6309,  July  30,  1991. 

[ISPARR3]       pDISP  12059-3,  Information  Technology  -  International  Standardized  Profiles  -  OS! 

Management  -  Common  Information  for  Management  Functions  -  Part  3:  Attributes  for 
Representing  Relationships,  July  1992. 

[ISPAR4]  pDISP  12059-4,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  4:  Alarm  Reporting, 
July  1992. 

[ISPCOMO]  pDISP  12059-0,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  0:  Common  Definitions 
for  Management  Function  Profiles,  July  1992. 

[ISPERM5]  pDISP  12059-5,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  5:  Event  Report 
Management,  July  1992. 
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[ISPFRM]  ISO/IEC  TR  10000-1 ,  Information  Technology  -  Framework  and  Taxonomy  of  International 
Standardized  Profiles  -  Part  1:  Framework,  ISO/IEC  JTCl/SGFS  N184.  9  February  1990. 

[ISPLC6]  pDISP  12059-€,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  6:  Log  Control,  July 
1992. 

[ISP0M1]  pbiSP  12059-1,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  1:  Object 
Management,  July  1992. 

[ISPSRVC]  ISO/I  EC  TR  8509,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Sen/ice 
Conventions,  TC97/SC16/1646. 

[ISPSTM2]  pDISP  12059-2,  Information  Technology  -  International  Standardized  Profiles  -  OSI 
Management  -  Common  Information  for  Management  Functions  -  Part  2:  State  Management, 
July  1992. 

[LCF]  ISO/IEC  IS  10164-6,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  6:  Log  Control  Function,  ISO/IEC  JTC1/SC21  N6361,  June  1991. 

[MGNM]*  CCITT  Recommendation  M.gnm,  Draft  Recommendation  (M.gnm)  Generic  Network 
Information  Model,  CCITT  SGIV,  Decembers,  1991. 

[MIM]  ISO/IEC  IS  10165-1,  Information  Technology -Open  Systems  Interconnection -Management 

Information  Services  -  Structure  of  Management  Information  -  Part  1:  Management 
Information  Model,  ISO/IEC  JTCl  /SC21  N6351 .  June  1 991 . 

[NMSIG1]  OIW  Endorsement/Comment  on  System  Management  Function  Taxonomy  (Including 
Proposed  Function  Taxonomy),  NMSIG-91  /1 64,  September  1991. 

[OMF]  ISO/IEC  IS  10164-1,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  1 :  Object  Management  Function,  ISO/IEC  JTCl  /SC21  N5184,  September 
1991. 

[0P1LIB]*  Forum  006,  Forum  Library  -  Volume  4:  OMNIPoint  1  Definitions,  Issue  1.0,  Network 
Management  Forum,  August  1992. 

[PPS]*  ISO/IEC  DIS  8823,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 

Connection  Oriented  Presentation  Protocol  Specification,  ISO/IEC  JTCl  /SC21  N2336, 5  April 
1988. 

[PSD]*  ISO/IEC  Final  Text  of  DIS  8822,  Information  Processing  Systems  -  Open  Systems 

Interconnection  -  Connection  Oriented  Presentation  Service  Definition,  ISO/IEC  JTCl  /SC21 
N2335,  5April  1988. 
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[ROSEPJ*       ISO/IEC  9072-2  -  Information  Processing  Systems  -  Text  Communications  -  Remote 
Operations  Part  2:  Protocol  Specification,  19  September  1989. 

[ROSES]*        ISO/IEC  9072-1,  Information  Processing  Systems  -  Text  Communications  -  Remote 
Operations  Part  1 :  Model,  Notation  and  Service  Definition,  19  September  1989. 

[SARF]  ISO/IEC  IS  10164-7,  information  Tecfinology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  7:  Security  Alarm  Reporting  Function,  July  1991 . 

[SATF]  ISO/IEC  DIS  10164-8,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  8:  Security  Audit  Trail  Function,  ISO/IEC  JTC1  /SC21  N7039,  June  1 992. 

[SMO]  ISO/IEC  IS  10040,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  Overview,  ISO/IEC  JTCl  /SC21  N6353,  August  1991. 

[STMF]  ISO/IEC  IS  10164-2,  Information  Technology  -  Open  Systems  Interconnection  -  Systems 

Management  -  Part  2:  State  Management  Function,  ISO/IEC  JTCl  /SC21  N51 85,  September 
1991. 
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4  Errata 

'Editor's  Note:  [  "Defect  Report"  material  (including  applicability)  may  be  included  here.] 


The  following  table  indicates  the  clause,  type,  and  reference  document  of  technical  errata  to  this  part. 


Erratum 
No. 

Type  & 
Date 
Entered 

Referenced 
Document 

Clause 

Comment 

1 

Technical 
6/91 

NMSIG- 

C7  1  /uo 

6.4.5 

This  clause,  previously  clause  6.2.6, 
was  moaiiiea  ana  movea  lo  ciause 
6.4.5  to  clarify  that  it  is  intended  as  a 
support  agreement  for  CMIP  rather 
than  a  usage  agreement  for  CMIS. 

2 

Alignment 
9/91 

NMSIG- 
91/110 
NMSIG- 
91/113 

5 

This  clause  has  been  updated  to 
reflect  alignment  changes  to  the 
relevant  base  standards  which  have 
just  progressed  to  IS  as  of  August, 
1991. 

3 

Technical 
9/91 

NMSIG- 
91/161 

6.2.2.2 

Move  text  from  ciause  5.1.2.1  to 
more  appropriate  clause  6.2.2.2  and 
clarify  required  support  for  minimal 
filter  complexity  to  align  with  the  DISP 
11183. 

4 

Technical 
9/91 

NMSIG- 
91/161 

6.2.3 

Remove  unnecessary  restrictions  on 
sending  CMIP  time  parameters. 

5 

Alignment 
9/91 

NMSIG- 
91/114 

6.1.1 

Change  reference  to  required 
application  context  support  to  align 
with  IS  version  of  [SMO]. 

6 

Technical 
9/91 

NMSIG- 
91/161 

6.3.3.1 

Remove  clause  requiring  mandatory 
attribute  list  in  successful  set 
response  because  considered 
redundant  information. 

7 

Alignment 
9/91 

NMSIG- 
91/120 

7 

Update  clause  to  reflect  alignment 
changes  to  the  relevant  base 
standards  which  have  progressed  to 
IS  as  of  August,  1991. 
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Erratum 
No. 

Tvoe  & 
Date 
Entered 

Referenced 
Document 

Clause 

Comment 

8 

Editorial 
9/91 

NMSIG- 
91/161 

6.3.6.1 

Move  clause  6.3.6.1  to  more 
appropriate  location  at  clause  7.1.5. 

i 

Alignment 

NMSIG- 

Update  reference  because  number  of 

3/92 

92/066 

clause  in  other  part  of  OIW  Stable 

Agreements  changed. 
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3  Status 

As  of  September  1 991 ,  the  Stable  management  communications  agreements  in  ciause  6  of  part  1 8  and  clause 
1 3.7  of  part  5  became  technically  equivalent  to  DISP 1 11 83.  The  DISP,  however,  is  a  more  rigorous  statement 
of  specifications.  Therefore,  it  has  been  the  stated  intent  of  the  NMSIG  to  directly  reference  the  ISP  1 11 83, 
Parts  1  through  3,  and  all  the  agreements  therein,  when  the  DISP  reaches  ISP  status.  Since  the  DISP  has  now 
progressed  to  ISP  11183  with  no  technical  changes,  the  NMSIG  Stable  management  communications 
agreements  in  clause  6  of  part  18  have  now  been  changed  to  point  directly  to  ISP  11183-1  through  -3 
[A0M1 PT1 ,  A0M1 PT2,  and  A0M1 PT2]. 

(Refer  to  the  Worl<ing  Implementation  Agreements  Document  for  additional  status  Information.) 
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4  Errata 

Editor's  Note:  [  "Defect  Report"  material  (including  applicability)  may  be  included  here.] 


The  following  table  indicates  the  clause,  type,  and  reference  document  of  technical  errata  to  this  part. 


Erratum 
No. 

Type  & 
Date 
Entered 

Referenced 
Document 

Clause 

Comment 

1 

Technical 

6/91 



NMSIG- 
91/08 

6.4.5 

This  clause,  previously  clause  6.2.6, 
was  modified  and  moved  to  clause 
6.4.5  to  clarify  that  it  is  intended  as  a 
support  agreement  for  CM  IP  rather 
than  a  usage  agreement  for  CM  IS. 

2 

Alignment 

9/91 

NMSIG- 
91/110 
NMSIG- 

91/113 

5 

This  clause  has  been  updated  to 
reflect  alignment  changes  to  the 
relevant  base  standards  which  have 
just  progressed  to  IS  as  of  August, 

1991. 

3 

Technical 
9/91 

NMSIG- 

91/161 

6.2.2.2 

Move  text  from  clause  5.1.2.1  to 
more  appropriate  clause  6.2.2.2  and 
clarify  required  support  for  minimal 
filter  complexity  to  align  with  the  DISP 
11183. 

4 

Technical 
9/91 

NMSIG- 
91/161 

6.2.3 

Remove  unnecessary  restrictions  on 
sending  CMIP  time  parameters. 

5 

Alignment 
9/91 

NMSIG- 

91/114 

6.1.1 

Change  reference  to  required 
application  context  support  to  align 
with  IS  version  of  [SMO]. 

6 

Technical 
9/91 

NMSIG- 

91/161 

6.3.3.1 

Remove  clause  requiring  mandatory 
attribute  list  in  successful  set 
response  because  considered 
redundant  information. 
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Erratum 
No. 

Type  & 
Date 
Entered 

Referenced 
Document 

Clause 



Comment 

7 

Alignment 
9/91 

NMSIG- 
91/120 

7 

Update  clause  to  reflect  alignment 
changes  to  the  relevant  base 
standards  which  have  progressed  to 
IS  as  of  August,  1991. 

8 

Editorial 
9/91 

NMSIG- 
91/161 

6.3.6.1 

Move  clause  6.3.6.1  to  more 
appropriate  location  at  clause  7.1.5. 

9 

Alignment 
3/92 

NMSIG- 
92/066 

6.1.3 

Update  reference  because  number  of 
clause  in  other  part  of  OIW  Stable 
Agreements  changed. 

10 

Alignment 
6/92 

NMSIG- 
92/093 

5.2  -  5.7 

Update  text  to  reference  appropriate 
A0M2X  pDISPs  because  have 
equivalent  agreements,  but  are  more 
rigorous. 

11 

Alignment 
6/92 

NMSIG  - 
92/200 

6 

Update  text  to  reference  ISP  1 1 183 
which  is  technically  equivalent  with  lA 
text  but  is  more  rigorous. 
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5     Management  Functions  and  Services 


5.1      General  Agreements 


5.1.1       Conventions  Used  In  SMF  Agreements 

Each  System  Management  Function  defines  a  set  of  services  referred  to  in  tliis  document  as  "SMF  services." 
Agreements  pertinent  to  SMF  services  are  provided  in  tfie  foliowing  subciauses.  Eacfi  subciause  contains  a 
series  of  tables,  as  foilows. 

For  eacli  SMF  service,  a  normative  table  references  text  agreements  which  constrain  the  usage  and/or  value 
of  the  associated  service  parameters.  Text  agreements  defined  elsewhere  in  this  document  are  referenced  by 
clause  number.  The  lack  of  a  row  or  reference  signifies  no  agreement  beyond  the  base  standard. 

These  tables  include  codes  which  specify  parameter  usage  for  request,  indication,  response,  and  confirmation 
service  primitives.  These  codes,  defined  in  subclause  1.8.3  of  these  agreements  (Classification  of 
Conformance),  inlSO/IECTR  10000-1  (Framework  and  Taxonomy  of  ISPs)  [ISPFRM],and  in  I  SO/I  EC  TR  8509 
(Service  Conventions)  [ISPSRVC],  are  repeated  here  for  reader  convenience: 


M  Mandatory 

0  Optional 

C(p)    If  Condition  p  exists,  then  parameter  is  mandatory;  othenvise,  the 

parameter  is  not  applicable. 
X  Excluded 

1  Out  Of  Scope 

In  these  agreements,  this  means  that,  for  the  corresponding  element, 

*  implementations  may  use  it  outside  the  scope  of  these  agreements, 

*  conformance  tests  shall  not  be  provided  for  it, 

*  implementations  may  conform  to  other  agreements  where  it  is  required, 

*  no  requirements  are  placed  on  either  transmitter  or  receiver  to  support 
it, 

*  receiver  actions  are  unspecified  when  present. 
Not  Applicable 

(=)  The  value  of  the  parameter  is  identical  to  the  corresponding  parameter  in 
the  interaction  described  by  the  preceding  related  service  primitive. 

U       The  use  of  the  parameter  is  a  service-user  option. 

P  The  parameter  is  mapped  directly  onto  the  corresponding  parameters  of 
the  CM  IS  service  primitive;  refer  to  subclause  6  for  agreements  regarding 
this  pass-through  parameter. 
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In  addition,  the  convention  "A>  B"  is  used  in  nornnative  tables  to  indicate  both  the  usage  specified  by  the  base 
standard  (A)  and  the  additional  constraint  imposed  by  these  agreements  (B).  This  convention  is  intended  to 
call  attention  to  agreements  which  modify  the  usage  of  a  service  parameter. 

Unless  otherwise  noted,  conditional  parameters  (C)  shall  be  present  according  to  the  conditions  defined  in 
[CMIS]  and  the  referenced  System  Management  Function  base  standard. 


5.1.2       General  Agreements  Referenced  By  Many  SMF  Services 

The  following  general  agreements  pertain  to  some  or  all  of  the  System  Management  Function  services  defined 
throughout  clause  5.  Normative  tables  for  each  SMF  service  reference  these  general  agreements  where 
applicable.  These  agreements  do  not  apply  to  SMF  services  and  parameters  which  do  not  reference  them. 


5.1.2.1        Maximum  Length  of  Notification  Identifier 

To  limit  implementation  complexity,  the  maximum  length  of  the  Notification  Identifier  parameter  shall  be  32  bits. 


5.1.2.2        Maximum  Number  of  SET  Items 

To  limit  implementation  complexity,  the  maximum  number  of  SET  items  contained  within  specified  SMF  service 
parameters  that  recipients  must  be  able  to  process  shall  be  64. 


5.1.2.3        Maximum  Length  of  Additional  Text 

To  limit  implementation  complexity,  the  maximum  length  of  the  Additional  Text  parameter  which  recipients 
must  be  able  to  process  shall  be  256  octets. 


5.1.2.4        Use  Of  Additional  Info 

Editor's  Note:  [The  Additional  Information  parameter,  described  in  [ARF]  clause  8.1.2.14,  includes  a 
"significance  indicator."  It  requires  that  "[e]ven  if  the  Additional  Information  parameter  is  not 
fully  understood,  an  event  report  indication  shall  be  issued  to  the  user.  Indication  that  the 
Additional  Information  parameter  is  not  fully  understood  is  a  local  matter."] 
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5.2      Object  Management  Function  Agreements 


5.2.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  object  management  standard  [OMF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  object 
management  standard  [OMF]  and  specified  in  [DMI] ,  with  the  exception  of  event  record  subclasses.  If  support 
for  the  log  control  standard  [LCF]  as  described  In  clause  5.7  is  claimed,  then  all  [OMF]  event  record 
subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the 
system  management  functional  units  specified  in  clause  10  of  [OMF]. 


5.2.2       Specific  Agreements 

See  [ISP0M1]  for  specification  of  agreements  for  the  Object  Management  Function. 


5.3      State  Management  Function  Agreements 


5.3.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  state  management  standard  [STMF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  state 
management  standard  [STMF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [STMF]  event  record 
subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the 
State  Change  Reporting  functional  unit  specified  in  clause  10  of  [STMF]. 


5.3.2       Specific  Agreements 

See  [ISPSTM2]  for  specification  of  agreements  for  the  State  Management  Function. 
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5.4      Attributes  For  Representing  Relationsliips  Agreements 


5.4.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  Attributes  For  Representing 
Relationships  standard  [ARR]. 

These  agreements  aiso  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  attributes 
for  representing  relationships  standard  [ARR]  and  specified  in  [DMI],  with  the  exception  of  event  record 
subclass.  If  support  for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARR] 
event  record  subclasses  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional 
negotiation  of  the  Relationship  Change  Reporting  functional  unit  specified  in  clause  10  of  [ARR]. 


5.4.2       Specific  Agreements 

See  [ISPARR3]  for  specification  of  agreements  for  Attributes  for  Representing  Relationships. 


5.5      Alarm  Reporting  Function  Agreements 


5.5.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  alarm  reporting  standard  [ARF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  alarm 
reporting  standard  [ARF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support  for 
the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [ARF]  event  record  subclasses 
shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  Alarm 
Reporting  functional  unit  specified  in  clause  10  of  [ARF]. 


5.5.2       Specific  Agreements 

See  [ISPAR4]  for  specification  of  agreements  for  the  Alarm  Reporting  Function. 
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5.6 


Event  Report  Management  Function  Agreements 


5.6.1 


General  Agreements 


These  agreements  require  support  for  the  SMF  services  defined  by  the  event  report  management  standard  i 
[ERMF].  I 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  event  report 
management  standard  [ERMF]  and  specified  in  [DMI].  These  agreements  permit  optional  negotiation  of  the 
Monitor  Event  Report  Management  and  Event  Report  Management  functional  units  specified  in  clause  10  of 
[ERMF]. 


5.6.2       Specific  Agreements 

See  [ISPERM5]  for  specification  of  agreements  for  the  Event  Report  Management  Function. 


5.7      Log  Control  Function  Agreements 

5.7.1  General  Agreements 

These  agreements  require  the  SMF  services  defined  by  the  log  control  standard  [LCF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  log  control 
standard  [LCF]  and  specified  in  [DMI]. 

If  any  other  function  defined  in  clause  5  that  supports  notifications  is  supported,  then  any  event  record  subclass 
defined  by  that  function  is  required  for  the  log  control  function. 

These  agreements  permit  optional  negotiation  for  log  control  and  monitor  log  control  functional 
units  specified  in  section  10  of  [LCF]. 

5.7.2  Specific  Agreements 

See  [ISPLC6]  for  specification  of  agreements  for  the  Log  Control  Function. 
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5.8      Security  Alarm  Reporting  Function  Agreements 


5.8.1  General  Agreements 

I  These  agreements  require  support  for  the  SMF  services  defined  by  the  security  alarm  reporting  standard 
[SARF]. 

i 

j  These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1  of  the  alamn 
i  reporting  standard  [SARF]  and  specified  in  [DMI],  with  the  exception  of  event  record  subclass.  If  support  for 
I  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [SARF]  event  record  subclasses 
j  shall  also  be  required  by  these  agreements.  These  agreements  permit  optional  negotiation  of  the  security 
alarm  reporting  function  as  specified  in  section  10  of  [SARF]. 

I 

5.8.2  Security  Alarm  Reporting 

This  subclause  provides  agreements  pertinent  to  the  Security  Alarm  Reporting  SMF  service  defined  by  section 
9.2  of  [SARF].  Subclause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through  parameters 
used  by  this  SMF  service. 


Table  1  -  Agreements  on  parameter  usage  pertinent  to  the  Security  Alarm  Reporting  SMF  service 


SMF  Security  Alarm  Reporting 
parameter 

Req 

Rsp 

SMF  agreements 

Event  Type 

M 

C(=) 

Event  Information 

Security  Alarm  Cause 

M 

Security  Alarm  Severity 

M 

Security  Alarm  Detector 

M 

[1] 

Service  User 

M 

Service  Provider 

M 

Notification  Identifier 

U 

5.1.2.1 

Correlated  Notifications 

U 

5.1.2.2 

Additional  Text 

U 

5.1.2.3 

Additional  Info 

U 

5.1.2.2,  5.1.2.4 
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[1  j  To  avoid  ambiguity,  the  Distinguislied  Name  form  of  this  parameter  shail  l^e  implemented  and 
may  be  used.  Use  of  Local  Distinguished  Name  and  Non-Specific  forms  are  beyond  the  scope 
of  these  agreements.  If  an  implementation  is  unable  to  decode  or  understand  the  semantics 
of  this  parameter,  an  appropriate  CMIS  error  (i.e..  Invalid  Attribute  Value)  shall  be  returned. 


5.9      Security  Audit  Trail  Function  Agreements 


5.9.1       General  Agreements 

These  agreements  require  support  for  the  SMF  services  defined  by  the  security  audit  trail  standard  [SATF]. 

These  agreements  also  require  conformance  to  the  abstract  syntaxes  identified  in  clause  1 1 .2  of  the  security 
audit  trail  standard  [SATF]  and  specified  in  [DMI],  with  the  exception  of  event  log  record  subclass.  If  support 
for  the  log  control  standard  [LCF]  as  described  in  clause  5.7  is  claimed,  then  all  [SATF]  event  log  record 
subclasses  shall  also  be  required  by  these  agreements. 


5.9.2       Security  Audit  Trail  Reporting  SMF  Service 

This  subclause  provides  agreements  pertinent  to  the  Security  Audit  Trail  Reporting  SMF  service  defined  by 
section  9.2  of  [SATF].  Clause  6  provides  agreements  pertinent  to  CMIS  services  and  pass-through  parameters 
used  by  this  SMF  service. 

Table  2  -  Agreements  on  parameter  usage  pertinent  to  the  Security  Audit  Trail  Reporting  SMF 

service 


1 

SMF  Security  Audit  Trail  parameter 

Req 

Rsp 

SMF  agreements 

Event  Type 

M 

C(=) 

5.9.2.1 

Event  Information 

Service  Report  Cause 

C(1) 

Notification  Identifier 

U 

5.1.2.3 

Correlated  Notifications 

u 

5.1.2.4 

Additional  Text 

u 

Additional  Info 

■ — — — 

U>l 

5.1.2.6 

C(1):  Manadatory  (M)  for  sen/iceReport 
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5.9.2.1  Notifications 

These  Implementors'  Agreements  require  support  for  both  the  seviceReport  arxi  usageReport  notification 
types. 

5.9.3       Security  Audit  Trail  Record 

This  subclause  is  a  piaceholder  for  agreements  pertaining  to  the  Security  Audit  Traii  Record  (SATR)  managed 
object  class. 

5.10  Objects  and  Attributes  for  Access  Control  Agreements 

(Refer  to  the  WorKing  Implementation  Agreements  Document.) 

5.1 1  Accounting  Meter  Function  Agreements 

(Refer  to  the  Worl<ing  implementation  Agreements  Document.) 

5.12  Workload  Monitoring  Function  Agreements 

(Refer  to  the  Worl<ing  Implementation  Agreements  Document.) 

5.13  Summarization  Function  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

5.14  Test  Management  Function  Agreements 

(Refer  to  the  Worl<ing  Implementation  Agreements  Document.) 
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5.15    Confidence  and  Diagnostic  Test  Classes  Agreements 

(Refer  to  the  Working  Implementation  Agreements  Document.) 


6     Management  Communications 

This  clause  covers  the  agreements  pertaining  to  the  use  of  associations  over  which  to  conduct  management 
communications,  and  agreements  for  management  communication,  itself,  by  reference  to  ISP  11183 
[A0M1PT1,  A0M1PT2,  and  A0M1PT3].  ISP  11183  defines  two  profiles,  A0M11  (Basic  Management 
Communications)  [A0M1PT3]  and  A0M12  (Enhanced  Management  Communications)  [A0M1PT2],  and 
defines  upper  layer  requirements  [A0M1 PT1  ]  for  each  of  these  profiles. 

For  rigorous  specification  of  the  agreements  relevant  to  clause  6,  Management  Communications,  see  ISP 
1 1 183  [A0M1 PT1 ,  A0M1 PT2,  and  A0M1 PT3]. 

6.1      Association  Policies 

Associations  are  established  using  the  procedures  described  in  [ACSEP]. 

6.1.1  Application  Context  Negotiation 

These  I  As  specify  the  negotiation  of  the  Systems  management  application  context  specified  in  [SMO].  Other 
application  contexts  are  outside  the  scope  of  these  agreements. 

6.1.2  Functional  Unit  Negotiation 

These  I  As  specify  that  System  Management  Functional  Units  are  negotiated  as  specified  in  [SMO]. 

6.1.3  Security  Aspects  of  Associations 

The  ACSE  authentication  mechanisms  and  associated  data  types  shall  be  as  defined  in  clause  9  (Upper  Layers 
Security)  of  part  12  of  the  OIW  Working  Agreements. 

Support  of  ACSE  authentication  is  optional. 
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7    Management  Information 

This  clause,  which  is  based  on  ISO  standards'  documents  [MIM]  and  [GDMO],  contains  agreements  regarding 
basic  concepts  and  modelling  techniques  related  to  management  information.  It  enumerates  agreements  on 
(i)  the  information  model  (sutx^lause  7.1)  and  (ii)  guidelines  for  defining  management  infornr^tion  (subclause 
7.2).  These  agreements  apply  to  developers  of  contributions  to  the  Management  Information  Library  (MIL). 
They  form  a  normative  part  of  the  standard;  hence  they  must  be  strictly  followed  while  defining  management 
Information.  It  is  not  within  the  scope  of  this  clause  to  mal<e  agreements  about  specific  elements  of 
management  information  or  to  define  such  specific  elements  of  management  infornnation.  Such  definitions 
and/or  agreements  can  be  obtained  via  the  Management  Information  Library. 


7.1      The  Information  Model 

When  modelling  nrianagement  information,  these  agreements  require  use  of  [MIM]  with  the  following  additional 
constraints. 


7.1.1  inheritance 

The  following  constraint  related  to  inheritance  is  enforced  In  order  to  remove  potential  ambiguities: 

During  the  lifetime  of  a  managed  object  instance,  each  of  its  attributes  must  have  a  value  that  is 
valid  for  the  attribute  syntax  of  that  attribute. 


7.1.2  Interoperability 


7.1.2.1        Interoperability  Provided  By  The  Agent  System 

Allomorphism,  as  specified  in  clause  5.2.3.1  of  [MIM],  is  out  of  scope.  Any  other  specification  within  the  [MiM] 
or  [GDMO]  that  refers  to  allomorphism  is  also  out  of  scope. 


7.1.2.2        Interoperability  Provided  By  The  Manager  System 

The  semantics  of  clause  5.2.3.2  of  [MIM]  are  supported.  A  manager  system  can  supply  the  object  identifier 
as  specified  in  clause  7.4.5  of  [GDMO]  to  specify  that  a  managed  object  should  perform  an  operation  as  a 
member  of  its  actual  class.  The  object  identifier  is  intended  to  be  used  in  requests  only,  and  shall  be 
interpreted  by  the  responder  as  a  requirement  to  return  its  real  object  class  value  in  the  response.  Agent 
systems  shall  support  this  object  identifier  as  defined  in  [MIM]  5.2.3.2  and  [GDMO]  7.4.5. 
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7.1.3 


Filter 


The  concept  of  filter  is  supported  as  specified  in  clause  6.  Restrictions  on  its  usage  are  specified  in  subclause 
6.2.2.2  of  these  agreements. 


7.1 .4       Management  Operations 

An  implementation  that  complies  with  these  agreements  shall  support  management  operations  as  defined  in 
clause  5.3.4  of  [MIM]  with  the  following  additional  clarification. 

[MIM]  clause  5.3.4.1  (2),  [DMI]  clause  6.14,  and  [GDMO]  clause  6.1.4  imply  that  the  object  class 
attribute  shall  not  be  included  in  the  create  request  Attribute  List  parameter.  [MIM]  states  that  any 
conflicting  duplicate  specifications  cause  the  request  to  fail. 


7.1 .5       Deletion  of  Objects  Containing  Objects 

The  error  'Processing  Failure'  shall  be  returned  if  a  managed  object  has  existing  contained  objects  and  the 
behavior  defined  for  that  object  prohibits  its  deletion  unless  all  contained  objects  have  been  deleted. 


7.2      Guidelines  for  the  Definition  of  Managenfient  Information 

This  subclause  contains  agreements  about  guidelines  for  the  definition  of  management  information,  as 
specified  in  [GDMO]. 


7.2.1       Syntactical  Definitions  of  Management  Information 


7.2.1 .1        Attribute  Template 

The  following  constraint  applies  to  the  Attribute  Template  specified  in  clause  9.7.2  of  [GDMO]: 

The  BEHAVIOUR  construct  may  be  omitted  only  if  a  behaviour  definition  has  been  inherited  from 
the  parent  attribute,  i.e.,  the  attribute  is  derived  from  another  attribute  whose  definition  contains  a  t 
BEHAVIOUR  construct.  ii 


I 
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7.2.2       Guidelines  For  Defining  Behaviour 

The  following  details  should  be  provided  in  the  set  of  specifications  defining  a  managed  object  class: 

a)  a  textual  description  of  the  network/system  resource(s)  the  managed  object  class  represents, 
including  their  functional  role; 

b)  a  description  of  the  relationships  that  can  occur  between  different  instances  of  the  nr^naged 
object  class  being  defined,  as  well  as  those  that  can  occur  between  instances  of  the  nonaged 
object  class  being  defined  and  instances  of  other  managed  object  classes; 

c)  a  description  of  the  operations  that  are  supported  by  the  managed  object  class,  with  precise 
definition  of  the  effects,  side  effects  if  any,  constraints,  response  notifications,  failure  modes; 

d)  specification  of  how  instances  of  this  managed  object  class  are  created  and  deleted,  particularly 
whether  they  can  be  created/deleted  via  the  management  CREATE/DELETE  operations; 

e)  a  description  of  notifications  that  can  be  generated,  the  conditions  that  generate  them  (e.g., 
crossing  of  a  threshold),  their  contents  and  side-effects,  if  any.  In  particular,  identify  all  the 
attributes  that  are  subject  to  the  AttributeChange  and  StateChange  notifications,  if  these 
notifications  are  supported; 

f)  other  constraints,  including  those  involving  other  managed  object  classes. 


7.2.3       Other  Guidelines 

The  Systems  Management  functions  have  defined  various  attributes  and  events,  as  indicated  in  clause  5  of 
these  agreements.  Object  definers  should  make  use  of  these  attributes  and  events  wherever  applicable. 


8  Conformance 


8.1  Introduction 

Clause  8  specifies  the  conformance  requirements  for  the  01 W  Network  Management  Implementation 
Agreements  (I As).  Implementors  of  products  will  provide  claims  of  conformance  to  these  requirements.  These 
claims  will  be  in  the  form  of  Protocol  Implementation  Conformance  Statements  (PICS)  and  Managed  Object 
Conformance  Statements  (MOCS).  These  requirements  will  also  be  used  to  develop  test  cases  which  will  be 
used  to  validate  claims  of  conformance.  This  clause  defines  the  general  conformance  requirements  and 
criteria  which  shall  be  used  as  a  basis  for  tests  of  implementations  claiming  conformance  to  these  agreements. 
Dependent  conformance  requirements  are  defined  in  the  context  in  which  they  are  used  (e.g.,  SMF  general 
conformance  requirements  include  CMIP  dependent  conformance  requirements  for  CMIS  services  used). 
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Editor's  Note:  [The  use  of  the  two  terms,  "general  conformance  class"  and  "dependent  conformance 
class",  Is  under  review.  When  a  final  answer  to  Question  Q1  /49.9  (on  the  long  term  solution 
to  general  and  dependent  conformance)  has  been  approved,  It  Is  Intended  to  clarify  and/or 
correct  this  conformance  section.] 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  introductory  text.) 


8.2      General  Requirements  of  Conformance 

Conformance  for  these  agreements  Is  designed  to  specify  a  well-defined  set  of  management  capabilities  and 
features.  For  the  purposes  of  organization  and  clarity  of  these  agreements,  management  has  been  divided  i 
into  three  categories.  Clauses  5  (Management  Functions  and  Services),  6  (Management  Communications) 
and  7  (Management  Information)  state  the  agreements  which  respectively  comprise  three  conformance 
categories.  Within  these  categories,  particular  conformance  categories  are  specified  which  delineate 
conformance  requirements  for  a  well-defined  and  bounded  set  of  management  capabilities  and  features  (e.g., 
within  the  Management  Functions  and  Sen/ices  conformance  categories,  a  conformance  category  is  specified 
which  defines  conformance  to  Alarm  Reporting  and  State  Management  Services).  Once  a  conformance 
category  is  delineated  which  specifies  the  set  of  requirements  for  that  category,  tests  can  be  developed  to 
evaluate  conformance  of  products  to  that  conformance  category.  And  finally,  for  some  conformance 
categories,  roles  (Manager,  Agent,  or  both)  are  specified.  One  or  more  roles  may  be  supported  for  those 
conformance  categories  to  which  an  implementation  is  conformant. 

The  development  of  conformance  categories  will  enable: 

a)  users  to  define  procurement  specifications; 

b)  vendors  to  define  management  capabilities  and  features; 

c)  conformance  test  houses  and  others  to  define  test  cases. 

To  be  conformant  to  the  I  As,  an  implementation  shall  be  conformant  to  at  least  one  of  the  following  categories: 

a)  Management  Communication;  j 

I'i 

b)  Management  Functions  and  Services;  5 

3 

c)  Management  Information.  ' 

Implementations  which  are  conformant  to  these  categories  shall  comply  with  the  requirements  stated  In  the  ' 
following  clause.  - 

1 
r 

i 
5 
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8.3      Specific  Conformance  Categories 


8.3.1  Management  Communication  Categories 

To  be  conformant  to  the  Management  Communication  categories,  an  implementation  shall  conform  to 
agreements  in  clause  6.  Conformance  to  management  communication  also  requires  an  implementor  to  state 
which  of  the  management  communication  profiles  specified  in  clause  6  are  supported  in  the  implementation. 
The  implementor's  statement  of  which  profile  is  supported  shall  be  indicated  in  a  CMIP  PICS  as  follows.  The 
implementor  shall  complete  the  PICS  proforma  as  specified  by  one  of  the  profiles  specified  in  clause  5. 

Note:    [Conformance  requirements  for  these  lAs,  relating  to  sen/ices  required  of  the  upper  layers  and  other 
ASEs,  are  discussed  in  part  5,  clause  13.7] 

8.3.2  Management  Functions  and  Services  Conformance  Categories 

To  be  conformant  to  the  Management  Functions  and  Services  categories,  an  implementation  shall  conform 
to  the  agreements  in  clause  5  on  at  least  one  of  the  categories  defined  below  in  either  a  manager  role,  an  agent 
role  or  both  roles.  [Note:  These  categories  are  aligned  with  the  proposed  A0M2x  Profiles  for  Systems 
Management  Functions.]  [NMSIG1]  Conformance  to  agreements  in  clause  5  requires  conformance  to 
referenced  ISO  standards/CCITT  Recommendations  and  to  all  other  clauses  referenced  in  5,  including 
dependent  conformance  to  the  underlying  services  required  by  the  SMFs. 

The  implementor  shall  state  which  of  the  following  conformance  categories  are  supported.  For  each  category, 
the  implementor  shall  complete  the  related  PICS  and  MOCS  proformas  to  indicate  which  functional  unit(s)  and 
roie(s)  are  supported. 


8.3.2.1        General  Management  Capabilities  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  A0M21 1  [A0M21 1].] 

Conformance  to  the  General  Management  Capabilities  Conformance  Category  requires  general  conformance 
to  the  Object  Management  Function  [OMF],  general  conformance  to  the  State  Management  Function  [STMF], 
general  conformance  to  the  Attributes  for  Representing  Relationships  Function  [ARR],  and  general 
conformance  to  the  Alarm  Reporting  Function  [ARF].  To  be  conformant  to  the  Object  Management  Function, 
an  implementation  shall  conform  to  the  requirements  stated  in  [OMF].  In  addition,  an  implementation  shall 
conform  to  clause  5.2  of  these  agreements  and  ail  other  clauses  referenced  in  5.2.  To  be  conformant  to  the 
State  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in  [STMF].  In 
addition,  an  implementation  shall  conform  to  clause  5.3  of  these  agreements  and  all  other  clauses  referenced 
in  5.3.  To  be  conformant  with  the  Attributes  for  Representing  Relationships  Function,  an  implementation  shall 
conform  to  the  requirements  stated  in  [ARR],  In  addition,  an  implementation  shall  conform  to  clause  5.4  of 
these  agreements  and  all  other  clauses  referenced  in  5.4.  To  be  conformant  to  the  Alarm  Reporting  Function, 
an  implementation  shall  conform  to  the  requirements  stated  in  [ARF].  In  addition,  an  implementation  shall 
conform  to  clause  5.5  of  these  agreements  and  all  clauses  referenced  in  5.5. 


25 


PART  18:  Network  Management 


September  1992  (Stable) 


8.3.2.2  Alarm  Reporting  and  State  Management  Capabilities  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM212  [AOM212].] 

Conformance  to  tlie  Alarm  Reporting  and  State  Management  Capabilities  Conformance  Category  requires 
general  conformance  to  the  State  Management  Function  [STMF],  general  conformance  to  the  Alarm  Reporting 
Function  [ARF],  and  dependent  conformance  to  the  Object  Management  Function  [OMF].  To  be  conformant 
to  the  State  Management  Function,  an  implementation  shall  conform  to  the  requirements  stated  in  [STMF]. 
In  addition,  an  implementation  shall  conform  to  clause  5.3  of  these  agreements  and  all  other  clauses 
referenced  in  5.3.  To  be  conformant  to  the  Alarm  Reporting  Function,  an  implementation  shall  conform  to  the 
requirements  stated  in  [ARF].  In  addition,  an  implementation  shall  conform  to  clause  5.5  of  these  agreements 
and  all  clauses  referenced  in  5.5. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  Alarm  Reporting  and  State 
Management  Capabilities  Conformance  Category  requires  support  for  the  PT-SET  and  PT-GET  elements  of 
procedure  in  clauses  1 1 .1 .6  and  1 1 .1 .7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as 
specified  by  the  implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.7  and 
clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  5.2.7  and  5.2.9.  The  implementation  need  only 
support  the  PT-SET  and  PT-GET  elements  of  procedure  as  applied  to  the  State  Management  Attributes 
identified  in  [STMF]  and  specified  in  [DMIj.  An  implementation  shall  also  conform  to  the  notifications  identified 
in  [STMF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1  (1)  basic  encoding(1)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-GET  and  PT-SET  elements  of  procedure  as  defined  in  clauses 
11.1.6  and  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntaxderived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )] ,  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF]. 


8.3.2.3  Alarm  Reporting  Capabilities  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM213  [AOM213].! 

Conformance  to  the  Alarm  Reporting  Capabilities  Conformance  Category  requires  general  conformance  to  the 
Alarm  Reporting  Function  [ARF].  To  be  conformant  to  the  Alarm  Reporting  Function,  an  implementation  shall 
conform  to  the  requirements  stated  in  [ARF].  In  addition,  an  implementation  shall  conform  to  clause  5.5  of 
these  agreements  and  all  clauses  referenced  in  5.5. 
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8.3.2.4        General  Event  Report  Management  Conformance  Category 
Note:    [This  category  corresponds  to  proposed  profile  AOM221  [AOM221].] 

Conformance  to  the  General  Event  Report  Management  Conformance  Category  requires  general  conformance 
to  the  Event  Report  Management  Function  [ERMF],  dependent  conformance  to  the  Object  Management 
Function  [OMF],  and  dependent  conformance  to  the  State  Management  Function  [STMF].  To  be  conformant 
to  the  Event  Report  Management  Function,  an  imf)lementation  shall  conform  to  the  requirements  stated  in 
[ERMF].  In  addition,  an  implementation  shall  conform  to  clause  5.6  of  these  agreements  and  all  clauses 
referenced  in  5.6. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  General  Event  Report 
Management  Conformance  Category  requires  support  for  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE, 
object  creation  reporting,  object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure 
in  clauses  11.1.1  through  1 1 .1 .7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified 
by  the  implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.2  through  clause 
5.2.7,  and  clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  these  clauses.  An  implementation 
shall  also  conform  to  the  notifications  Identified  in  [OMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  State  Management  Function  required  by  the  General  Event  Report 
Management  Conformance  Category  requires  support  for  the  state  change  reporting  elements  of  procedure 
in  clause  11.1  of  [STMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the 
implementor  in  the  PICS,  in  addition,  an  implementation  shall  conform  to  clause  5.3.2  of  these  agreements 
and  all  clauses  referenced  by  clause  5.3.2.  An  implementation  shall  also  conform  to  the  notifications  identified 
in  [STMF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  reporting, 
object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  as  defined  In  clauses 
11.1.1  through  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )],  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [OMF]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asnl  (1)  basic  encoding(l)].  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  state  change  reporting  elements  of  procedure  as  defined  in  clause 
11.1  of  [STMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )] ,  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.6  of  [STMF]. 
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8.3.2.5        General  Log  Control  Conformance  Category 

Note:    [This  category  corresponds  to  proposed  profile  AOM231  [AOM231].] 

Conformance  to  the  Log  Control  Conformance  Category  requires  general  conformance  to  the  Log  Control 
Function  [LCF],  dependent  conformance  to  the  Object  Management  Function  [OMF],  dependent  conformance 
to  the  State  Management  Function  [STMF]  and  dependent  confornr»ance  to  the  Alarm  Reporting  Function 
[ARF].  To  be  conformant  to  the  Log  Control  Function,  an  implementation  shall  conform  to  the  requirements 
stated  in  [LCF].  Inaddition,  an  implementation  shall  conform  to  clause  5.7  of  these  agreements  and  all  clauses 
reference!  in  5.7. 

Dependent  conformance  to  the  Object  Management  Function  required  by  the  General  Log  Control 
Conformance  Category  requires  support  for  the  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation 
reporting,  object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  in  clauses 
1 1.1.1  through  1 1.1.7  of  [OMF]  in  either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the 
implementor  in  the  PICS.  In  addition,  an  implementation  shall  conform  to  clause  5.2.2  through  clause  5.2.7, 
and  clause  5.2.9  of  these  agreements  and  all  clauses  referenced  in  these  clauses.  An  implementation  shall  also 
conform  to  the  notifications  identified  in  [OMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  State  Management  Function  required  by  the  General  Log  Control  Conformance 
Category  requires  support  for  the  state  change  reporting  elements  of  procedure  in  clause  11.1  of  [STMF]  in 
either  the  agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  implementor  in  the  PICS.  In  addition, 
an  implementation  shall  conform  to  clause  5.3.2  of  these  agreements  and  all  clauses  referenced  by  clause 
5.3.2.  An  implementation  shall  also  conform  to  the  notifications  identified  in  [STMF]  and  specified  in  [DMI]. 

Dependent  conformance  to  the  Alarm  Reporting  Function  required  by  the  General  Log  Control  Conformance 
Category  requires  support  for  the  alarm  reporting  elements  of  procedure  in  clause  11.1  of  [ARF]  in  either  the 
agent  role,  the  manager  role,  or  both  roles  as  specified  by  the  implementor  in  the  PICS.  In  addition,  an 
implementation  shall  conform  to  clause  5.5.2  of  these  agreements  and  all  clauses  referenced  by  clause  5.5.2. 
An  implementation  shall  also  conform  to  the  notifications  identified  in  [ARF]  and  specified  in  [DMI]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asnl  (1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  requiredto  supportthe  PT-SET,  PT-GET,  PT-CREATE,  PT-DELETE,  object  creation  reporting, 
object  deletion  reporting,  and  attribute  value  change  reporting  elements  of  procedure  as  defined  in  clauses 
11.1.1  through  11.1.7  of  [OMF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[joint-iso-ccitt  asnl  (1 )  basic  encoding(1 )] ,  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [OMF]. 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asn1(1)  basic  encoding(l)],  for  the  purpose 
of  generating  and  interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCI"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  state  change  reporting  elements  of  procedure  as  defined  in  clause 
11.1  of  [STMF]. 
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The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in[BER]  named 
[jolnt-lso-ccitt  asm  (1 )  basic  encoding(1 )].  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  11.2.6  of  [STMF] . 

For  each  role  claimed  to  be  supported  in  the  PICS,  an  implementation  shall  support  the  transfer  syntax  derived 
from  the  encoding  rules  defined  in  [BER]  named  [joint-iso-ccitt  asnl  (1)  basic  encodlng(l)],  for  the  purpose 
of  generating  and  Interpreting  the  MAPDUs  required  to  support  that  portion  of  the  "CMIP-PCi"  abstract  syntax 
defined  in  [CMIP]  required  to  support  the  alarm  reporting  elements  of  procedure  as  defined  in  clause  1 1 .1  of 
[ARF]. 

The  implementation  shall  support  the  transfer  syntax  derived  from  the  encoding  rules  specified  in  [BER]  named 
[jolnt-lso-ccitt  asm  (1 )  basic  encoding(1 )] ,  for  the  purpose  of  generating  and  interpreting  the  MAPDUs  defined 
by  the  abstract  data  types  referenced  in  1 1 .2.5  of  [ARF]. 


8.3.3       Management  Information  Conformance  Category 

To  be  conformant  to  the  Management  information  Conformance  Category,  an  implementation  shall  include 
at  least  one  managed  object  defined  as  specified  by  clause  7.  The  requirements  for  managing  this  managed 
object  shall  not  conflict  with  the  specifications  in  clauses  5  and  6.  Managed  object  class  definitions  shall  be 
provided  either  in  full  or  by  reference.  Registered  object  identifiers  shall  be  associated  With  any  such  managed 
object  class  definition  and  supporting  definitions  (e.g.,  attributes,  name  bindings).  Ail  mandatory  abstract 
syntaxes  and  semantics  associated  with  those  identifiers  shall  be  used.  Note  that  all  managed  objects  and 
supporting  definitions  in  Annex  A  satisfy  these  conformance  requirements. 

An  implementation  is  conformant  to  a  managed  object  class  definition  if  it  supports  all  the  mandatory  packages 
specified  in  the  managed  object  class  as  well  as  all  associated  information  (e.g.,  attributes,  notifications, 
actions,  parameters)  referenced  in  these  packages  and  at  least  one  name  binding  that  may  be  used  to  support 
the  naming  of  instances  of  this  managed  object  class.  Although  it  is  not  necessary  to  be  conformant  to  all 
superior  object  classes  in  the  containment  tree  of  an  instance  of  a  conformant  managed  object  class,  all  name 
bindings  arid  naming  attributes  necessary  to  access  that  object  instance  shall  be  publicly  available. 


8.3.3.1         MOCS  Proforma 

The  implementor  shall  provide  a  statement  specifying  which  managed  object  classes  are  supported.  A  MOCS 
proforma  shall  be  completed  by  the  implementor  for  each  managed  object  class  supported. 

Editor's  Note:  [The  CD  Version  of  ISO/IEC  10165-6  (Requirements  and  Guidelines  for  Implementation 
Conformance  Statement  Proformas  Associated  with  Management  Information)  is  now 
available.  MOCS  Proformas  for  each  managed  object  class  supported  should  be  developed 
consistent  with  10165-6  [MOCS].] 

For  each  managed  object  class  supported,  the  following  shall  be  supplied: 
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a)  a  statement  of  pragmatic  constraints  (e.g.,  attribute  values/ranges,  initial  vaiues)  supported, 
unless  such  constraints  are  defined  in  the  managed  object  class  definition; 

b)  a  statement  of  conditional  packages  supported; 

c)  a  statement  of  role(s)  (manager,  agent,  or  both)  in  which  the  object  class  definition  is 
supported. 

Editor's  Note:  [CD  10165-6  does  not  currently  distinguish  roles.] 
8.3.4       Management  Application  Contexts 

The  implementation  shall  support  at  least  the  application  context  for  systems  management  defined  in  ISO/IEC 
10040  [SMO]. 

Note:    [Such  a  statement  is  required  by  [SMO]  clause  7.2.] 

Note:    [Such  a  statement  is  required  by  part  5,  clause  13.7,  which  discusses  conformance  requirements 
for  these  lAs,  as  related  to  services  required  of  the  upper  layers  and  other  ASEs.] 

8.4      Demonstration  of  Conformance 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

8.4.1  Management  Communication 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

8.4.2  Management  Functions  and  Services 

(Refer  to  the  Working  Implementation  Agreements  Document.) 

8.4.3  Management  Information 

(Refer  to  the  Working  Implementation  Agreements  Document.) 


30 


PART  18:  Network  Management 


September  1992  (Stable) 


Annex  A  (informative) 

Management  Information  Library  (MIL) 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  information.) 
A.1  Introduction 

(Refer  to  the  Working  implementation  Agreements  Document.) 
A.2  Rules  and  Procedures 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.3  General  Guidelines 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
A.4  Harmonized  Library 

The  definitions  specified  in  this  clause  can  be  referenced  by  using  the  label  "0P1  Library  Vol.  1"  (e.g.,  "0P1 
Library  Vol.  TrcbmputerSystem). 

By  inclusion  of  the  managed  object  (MO)  definitions  and  the  object  identifiers  in  Annex  A  and  Annex  B, 
respectively,  of  the  Stable  Implementors'  Agreements  (SIAs),  these  managed  object  (MO)  definitions  have 
become  formally  registered.  Implementors  of  part  18  of  the  SIAs  do  not  have  to  support  any  of  these  MOs. 
However,  even  though  Annex  A  and  Annex  B  are  informative  annexes,  any  implementation  that  claims  to 
confomi  to  these  definitions  must  treat  these  definitions  as  normative  and  comply  with  the  relevant  portions 
of  Annex  A.4  and  A.5,  and  Annex  B. 

A.4.1  Managed  Object  Classes  and  Mandatory  Packages 

A.4. 1.1  Computer  System 

computerSystem     MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":top; 

CHARACTERIZED  BY  computerSystemPkg; 

CONDITIONAL  PACKAGES 

peripheralNamePkg  PRESENT  IF  !an  instance  supports  it  and  the 

peripheralListPkg  is  NOT  present!, 
peripheralListPkg  PRESENT  IF  !an  instance  supports  it  and  the 

peripheralNamePkg  is  NOT  present!, 
processingEntityNamePkg    PRESENT  IF  Ian  instance  supports  it  and  the 

process! ngEntityListPkg  is  NOT  present!, 
processingEntityListPkg    PRESENT  IF  !an  instance  supports  it  and  the 

processingEntityNamePkg  is  NOT  present!. 
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systemTimePlcg  PRESENT  IF  !an  instance  supports  it!, 

upTimePkg  PRESENT  IF  !an  instance  supports  it!, 

"Rec.  H.3100  :  1 992" :userLabe I Package 

PRESENT  IF  !an  instance  supports  it!, 
usageStatePkg  PRESENT  IF  ! resource  can  detect  usage!; 

REGISTERED  AS    <x-objectClass  1>; 


computerSystefliPkg  PACKAGE 

BEHAVIOUR  computerSystemPkgDef inition, 
computerSystemPkgBehavi our; 

ATTRIBUTES 

computerSystemld  GET, 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":operationalState  GET, 
■  "Rec.  X.721      ISO/IEC  10165-2  :  1992":administrativeState  GET-REPLACE, 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":alarmStatus  GET-REPLACE  ADD-REMOVE, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":avai labi lityStatus  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721      ISO/IEC  10165-2  :  1992": operational State 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":alarmStatus 
"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":avai labi I i tyStatus; 


NOTIFICATIONS 

"Rec.  X.721  j  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  !  ISO/IEC  10165-2 


1992" robjectCreat ion, 

1 992" : ob j  ec tDe I et  i  on , 

1 992" : a 1 1  r  i  buteVa I ueChange , 

1992":stateChange, 

1 992" : process  i  ngE  r  r or A I  a  rm, 

1 992" : envi ronmenta I A I arm, 

1992":equipnientAlarm; ; 


computerSystemPkgDef inition  BEHAVIOUR 


DEFINED  AS 

!The  Computer  System  nnanaged  object  class  represents  the  aggregate  of  components  which,  when 
considered  as  a  whole,  is  capable  of  performing  data  processing,  storage,  and  retrieval  functions. 
In  order  to  perform  its  function,  the  computer  system  may  have  a  variety  of  components  including 
processing  entities,  terminals,  disk  drives,  printers,  etc. 

The  Computer  System  is  intended  to  represent  an  aggregation  of  other  objects,  and  can  model  either 
self-contained  computer  systems  or  computer  systems  which  are  physically  distributed,  possibly  over 
a  wide  geographical  area.    An  instance  of  the  Computer  System  managed  object  class  may  have 
subordinate  managed  objects  representing  the  individual  entities  within  the  computer  system. 
Examples  are  entities  such  as  disks,  operating  systems  and  processing  entities. 

Since  the  Computer  System  may  be  physically  distributed,  it  is  not  appropriate  to  model  the  computer 
system  managed  object  class  as  a  subclass  of  the  Equipment  managed  object  class  (since  Equipment 
implies  a  single  physical  location  through  its  location  attribute).    However,  there  can  be  cases 
where  the  Computer  System  is  not  physically  distributed,  in  which  case  a  Name  Binding  allowing 
Computer  System  to  be  named  by  OMNIPoint  Equipment  is  permissible. 

It  is  not  appropriate  to  model  Computer  System  as  a  subclass  of  the  DMI  System  managed  object  class. 
Unlike  Computer  System,  the  DMI  System  is  a  "container"  object  class  which  is  instantiated  in 
managed  systems  and  exists  inainly  to  name  the  managed  and  support  objects  it  makes  visible.!; 


computerSystemPkgBehavi our  BEHAVIOUR 


DEFINED  AS 
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!A  value  for  the  computerSystemld  attribute  can  only  be  provided  when  the  object  is  created. 
Furthermore,  this  attribute  value  may  not  change  once  the  managed  object  has  been  instantiated. 
Thus,  this  attribute  is  never  the  subject  of  an  AttributeValueChange  Notification. 

Conditions  under  which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted. 
All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrativeState,  operational State,  and  availability  status. 

The  StateChange  notification  is  not  emitted  when  the  alarmStatus  attribute  changes  value.  (This  is 
to  avoid  duplication  of  notifications.) 

Since  every  combination  of  state  attribute  values  may  not  be  appropriate  for  particular  kinds  of 
computer  systems,  only  appropriate  combinations  need  be  supported. 

The  processingErrorAlarm  notification  is  emitted  when  the  computerSystem  resource  experiences  any  of 
the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem,  version  mismatch, 
corrupt  data,  software  error,  underlying  resource  unavailable).!; 

A.4.1.2  Connection  Oriented  Transport  Protocol  Layer  Entity 

coTransportProtocolLayerEntity      MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":top; 

CHARACTERIZED  BY  coTransportProtocolLayerEntityPkg; 


CONDITIONAL  PACKAGES 

manuf acturerL  i  stPkg 

manufacturerMamePkg 

productLabelPkg 

opVersionPkg 

serialNumberPkg 

typeTextPkg 

upTimePkg 

i ncomi ngProtoco IE r rorPkg 
outgoingProtocolErrorPkg 
checksumPDUsD  i  scardedPkg 
maxPDUSizelVPkg 


usageStatePkg 
REGISTERED  AS  <x-objectClass  2>; 


PRESENT  IF  !an  instance  supports  it  and  the 

manuf acturerNamePkg  is  NOT  present!, 

PRESENT  IF  !an  instance  supports  it  and  the 

manufacturerListPkg  is  NOT  present!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !an  instance  supports  it!, 

PRESENT  IF  !the  "OPI  Library  Vol.  2  :  1992": transport 

Connect  ion I VMO  object  class  is  not  used  to 

provide  this  initial  value!, 

PRESENT  IF  ! resource  can  detect  usage!; 


coT  r anspor tP  rotoco I LayerEnt  i  tyPkg  PACKAGE 

BEHAVIOUR    coTransportProtocolLayerEntityPkgDef inition, 
coTransportProtocolLayerEntityPkgBehaviour; 


ATTRIBUTES 

coTransportProtocol LayerEnt ityld 
transportEntityType  GET, 
localTransportAddresses  GET, 


PERMITTED  VALUES  SYNTAX-1 .GraphicString64  GET, 
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act iveConnect ions  PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
maxConnections     PERMITTED  VALUES  SYNTAX-1. I nteger32  GET, 


"Rec. 
"Rec. 
"Rec. 
"Rec. 


,721 
,721 
,721 
,721 


"Rec.  X.721 


"Rec.  X.721 


"Rec.  X,721 


"Rec.  X.721 


"Rec.  X.721 


"Rec.  X.721 


"Rec.  X,721 


"Rec.  X.721 


"Rec.  X.721 


ATTRIBUTE 
"Rec. 


GROUPS 
X.721 


ISO/IEC  10165-2  :  1992":adninistrativeState  GET-REPLACE, 
ISO/IEC  10165-2  :  1992": operational State  GET, 
ISO/IEC  10165-2  :  1992":alariiiStatus  GET-REPLACE  ADD-REMOVE, 
ISO/IEC  10165-2  :  1992":outgoingConnectionRec|uestsCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992": incomingConnectionRequestsCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992":outgoingConnectionRejectErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992": incomingConnectionRejectErrorCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992":outgoingDisconnectErrorCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992": incomingOisconnectErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992": incomingOisconnectCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992":outgoingDisconnectCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
ISO/IEC  10165-2  :  1992":octetsReceivedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 


Rec. 
Rec. 
Rec. 


X.721 
X.721 
X.721 


I 


ISO/IEC  10165-2  :  1992":state 
ISO/IEC  10165-2  : 
ISO/IEC  10165-2  : 
ISO/IEC  10165-2  : 


1992":administrativeState 
1992": operational State 
1992":alarinStatus; 


ACTIONS      activate,  deactivate; 


NOTIFICATIONS 


"Rec. 
"Rec. 
"Rec. 
"Rec. 
"Rec. 


,721 
.721 
,721 
.721 
.721 


ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 


1992" : ob j  ectCreat  i  on, 

1992" :objectDelet ion, 

1 992" : at t  r  i  buteVa lueChange, 

1992":stateChange, 

1 992" : process  i  ngE  r  ror A I arm; ; 


coTransportProtocolLayerEntityPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!The  coTransportProtocolLayerEntity  managed  object  class  represents  an  instantiation    of  any 
connect  ion- oriented  transport  layer  protocol  (e.g.,  the  ISO  Transport  Protocol      layer  or  the 
Internet  Transmission  Control  Protocol  (TCP)  Layer).    The  transport     protocol  layer  is  layer  four 
of  the  OSI  Reference  model.    It  provides  for  the     transparent  transference  of  data  between  two  peer 
entities.    It  relieves  its  users     from  any  concerns  about  the  detailed  way  in  which  supporting 
communication  media  are     utilized  to  achieve  this  transfer.    The  connect  ion- oriented  transport 
protocol  layer     entity  makes  use  of  a  transport  connection  for  the  purpose  of  transferring  data. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connect  ion- oriented  transport  protocol  -  rather  it  contains  characteristics  common  across  various 
different  connect  ion- oriented  transport  layer  protocols.    This  managed  object  class  is  not  intended 
to  override  any  transport  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level 
view  of  a  connect  ion- oriented  transport  layer  protocol  and  complements  the  protocol -specific  views 
being  defined  in  the  standards.!; 


coTransportProtocolLayerEntityPkgBehaviour  BEHAVIOUR 
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DEFINED  AS 

tConditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.  In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  Be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  localTransportAddresses,  maxConnections,  transportEntityType,  and  all  counter  attributes 
(only  when  they  wrap).    All  attributeValueChange  notifications  shall  include  the  Attribute 
Identifier  List  parameter.    All  attributeValueChange  notifications  which  report  counter  attribute 
wraps  shall  contain  the  maximum  counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

The  stateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
adninistrativeState  and  operational  State. 

The  processingErrorAlarm  notification  is  emitted  when  the  coTransportProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific  connection- 
oriented  transport  protocol.    ISO/IEC  10733  [TLM]  defines  specific  objects  for  managing  OSI  transport 
protocol  layer  entities. 

A.4.1.3  Connectionless  Network  Protocol  Layer  Entity 


clNetworkProtocolLayerEntity      MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  top; 

CHARACTERIZED  BY  clNetworkProtocolLayerEntityPkg; 


CONDITIONAL  PACKAGES 


manuf acturerL  i  stPkg 

manufacturerNamePkg 

productLabelPkg 

opVersionPkg 

serialNumberPkg 

typeTextPkg 

upTimePkg 


PRESENT  IF  >an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
PRESENT  IF  !an  instance  supports  it  and  the 

manufacturerListPkg  is  NOT  present!, 
IF  !an  instance  supports  it!, 
IF  !an  instance  supports  it!, 
IF  !an  instance  supports  it!, 
!an  instance  supports  it!. 


PRESENT 
PRESENT 
PRESENT 
PRESENT 
PRESENT 


IF 

IF  !an  instance  supports  it!; 


REGISTERED  AS    Cx-objectClass  3>; 


clNetworkProtocolLayerEntityPkg  PACKAGE 

BEHAVIOUR    clNetworkProtocolLayerEntityPkgDef inition, 
clNetworkProtocolLayerEntityPkgBehaviour; 

ATTRIBUTES 

clNetworkProtocolLayerEntityld  PERMITTED  VALUES  SYNTAX-1 .GraphicString64  GET, 
networkEnt i tyType  GET, 

localNetworkAddresses    GET-REPLACE  ADD-REMOVE, 
nPDUTimeToLive    PERMITTED  VALUES  SYNTAX-1 . Integer32  GET-REPLACE, 


"Rec. 
"Rec. 
"Rec. 
"Rec. 


.721 
,721 
,721 
,721 


I 


ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 

ISO/IEC  10165-2 


"Rec.  X.721  I  ISO/IEC  10165-2 


1992":administrativeState  GET-REPLACE, 
1992": operational State  GET, 
1992":alarmStatus    GET-REPLACE  ADD-REMOVE, 
1 992" : pdusSentCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
1 992" : pdusRecei  vedCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
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"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsReceivedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusForwardedCounter    PERMITTED  VALUES  SYNTAX- 1. I nteger32  GET, 
pdusReasmbldOKCounter    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusReasmbldFailCounter    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
pdusDiscardedCounter     PERMITTED  VALUES  SYNTAX- 1.1nteger32  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":state 

•  "Rec.  X.721  !  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721      ISO/IEC  10165-2  :  1992":operationalState 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":alarmStatus; 

ACTIONS      activate,  deactivate; 


NOTIFICATIONS 

"Rec.  X.721  I  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  ISO/IEC  10165-2 

"Rec.  X.721  !  ISO/IEC  10165-2 


1992" :objectCreat ion, 
1992":objectDeletion, 
1992":attributeValueChange, 
1 992" : process  i  ngE  r  rorA I a  rm, 
1 992" :  coirmuni  cat  i  onsA  I  arm, 
1992" : stateChange; ; 


c I Net wor kProtoco I LayerEnt  i  tyPkgDef  i  n  i  t  i  on   BE  HAV I OUR 
DEFINED  AS 

!The  clNetworkProtocolLayerEntity  managed  object  class  represents  an  instantiation  of  a 
connectionless  network  protocol  layer.    The  network  protocol  layer  provides  network  services  for  the 
transparent  transfer  of  data  between  peer  transport  entities.    It  relieves  the  transport  protocol 
layer  from  the  need  to  know  anything  about  the  underlying  network  technologies  used  to  achieve  data 
transfer. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connectionless  network  protocol;  instead,  it  contains  characteristics  conmon  across  various 
different  connectionless  network  layer  protocols.    This  managed  object  class  is  not  intended  to 
override  any  network  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level  view  of 
a  connectionless  network  layer  protocol  and  complements  the  protocol -specific  views    being  defined 
in  the  standards. 

An  instance  of  this  managed  object  class  supports  only  one  type  of  protocol.!; 
clNetworkProtocol LayerEnt ityPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

{Conditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.  In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  be  emitted. 

The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  networkEntityType,  localNetworkAddresses,  nPDUTimeToLive,  and  all  counter  attributes  (only 
when  they  wrap).    All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List 
parameter.    All  attributeValueChange  notifications  which  report  counter  attribute  wraps  shall 
contain  the  maximum  counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

The  StateChange  notification  is  emitted  when  any  of  the  following  attributes  change  in  value: 
administrativeState  and  operational  State. 

The  communicationsAlarm  notification  is  emitted  when  the  clNetworkProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  1016A-4  (e.g.,  loss  of  signal,  local 
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transmission  error,  remote  transmission  error).  In  particular,  this  notification  is  used  to  report 
when  a  data  NPDU  is  discarded  for  any  reason  other  than  network  congestion. 

The  processingErrorAlarm  notification  is  emitted  when  the  clNetworkProtocolLayerEntity  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  uncvai lable). I ; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connectionless  network  protocol.    ISO/IEC  10737  [NLM]  defines  specific  objects  for  managing  OSI  network 
protocol  layer  entities. 

A.4.1.4  OMNIPoint  Equipment 

--  This  definition  is  subclassed  from  CCITT  H.3100  Equipment,  adding  the  following  items: 

Mandatory  AttributeChange,  ObjectCreation,  ObjectDeletion  Notifications 
Mandatory  Environmental,  Processing  Error,  and  Equipment  Alarm  Notifications 
Mandatory  Administrative  and  Operational  State  Attributes  and  State  Change  Notification 
CREATE/DELETE  operations  and  behaviours  (in  name  bindings) 

Conditional  Contact,  Customer,  Function,  Manufacturer,  OMNIPoint  Network,  Service,  Software 

and  Vendor  Name  and  List  Packages 

Conditional  Product  and  Serial  Number  Packages 

Conditional  Type  Text  Package 

Conditional  Location  Pointer  Package 

--  ANSI  T1M1.5  concerns  regarding  physical  vs.  functional  modelling  were  resolved  by  excluding  the  Forun 

--  R1  Equipment  Type  attribute  from  the  OMNIPoint  definition.    The  TypeText,  FunctionName,  and/or 

--  FunctionList  attributes  may  be  used  to  carry  (as  graphic  strings  or  pointers)  information  concerning 

--  the  function(s)  supported  by  the  physical  Equipment.    It  is  expected  that  Forum  R1  to  OMNIPoint  1 

--  mapping  rules  will  define  a  translation  between  Forum  R1  EquipmentTyfje  enumerations  and  these  OMNIPoint 

--  Equipment  attributes. 


opEquipment  MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  M.3100  :  1 992": equipment ; 

CHARACTERIZED  BY 

opEquipmentPkg, 

"Rec.  M.3100  :  1992":create0eleteNotif icationsPackage, 

"Rec.  M.3100  :  1992":attributeValueChangeNotif icationPackage, 

"Rec.  M.3100  :  1992":stateChangeNotif icationPackage, 

"Rec.  M.3100  :  1992":a<±ninistrativeOperationalStatesPackage, 

"Rec.  M.3100  :  1992":environmentalAlarmPackage, 

"Rec.  M.3100  :  1992": process ingErrorA I armPackage, 

"Rec.  M.3100  :  1992":equipmentsEquipmentAlarmPackage; 


CONDITIONAL  PACKAGES 


contactListPkg 

PRESENT 

contactNamePkg 

PRESENT 

customerListPkg 

PRESENT 

customerNamePkg 

PRESENT 

functionListPkg 

PRESENT 

functionNamePkg 

PRESENT 

I ocat  i  onPo  i  nt erPkg 

PRESENT 

IF  !an  instance  supports  it  and  the 

contactNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

contactListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

customerNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

customerListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

functionNamePkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

functionListPkg  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

"Rec.  M.3100  :  1992": 
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manufacturerListPkg  PRESENT 

manufacturerNamePkg  PRESENT 

opNetworkListPkg  PRESENT 

opNetworkNamePkg  PRESENT 

opVersionPkg  PRESENT 

productLaiselPkg  PRESENT 

serialNumberPkg  PRESENT 

serviceListPkg  PRESENT 

serviceNamePkg  PRESENT 

softwareListPkg  PRESENT 

softwareNamePkg  PRESENT 

typeTextPkg  PRESENT 

usageStatePkg  PRESENT 

vendorListPkg  PRESENT 


locationNamePackage  is  NOT  present!, 
IF  !an  instance  supports  it  and  the 

manufacturerNamePkg  is  NOT  present!, 
fan  instance  supports  it  and  the 
manufacturerListPkg  is  NOT  present!, 
Ian  instance  supports  it  and  the 
opNetworkNamePkg  is  NOT  present!, 
Ian  instance  supports  it  and  the 
opNetworkListPkg  is  NOT  present!, 
IF  !"Rec.  M.3100  :  1992": 

versionPackage  is  also  present!, 
!an  instance  supports  it!, 
!an  instance  supports  it!, 
Ian  instance  supports  it  and  the 
serviceNamePkg  is  NOT  present!, 
Ian  instance  supports  it  and  the 
serviceListPkg  is  NOT  present!, 
Ian  instance  supports  it  and  the 
softwareNamePkg  is  NOT  present!, 
Ian  instance  supports  it  and  the 
softwareListPkg  is  NOT  present!, 
Ian  instance  supports  it!, 
I  resource  can  detect  usage! , 
Ian  instance  supports  it  and  the 
"Rec.  M.3100  :  1992": 
vendorNamePackage  is  NOT  present  I; 


IF 


IF 


IF 


REGISTERED  AS    <x-objectClass  4>; 

opEquipmentPkg  PACKAGE 

BEHAVIOUR  opEquipmentPkgBehaviour; 

--    opEquipmentPkgDef inition  inherited  from  Rec.  M.3100  Equipment 

ATTRIBUTES 

"Rec.  M.3100  :  1992":equipmentld  PERMITTED  VALUES  SYNTAX- 1 .EquipmentldRange  GET; 

ATTRIBUTE  GROUPS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":administrativeState 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1 992": operational State; ; 


OpEquipmentPkgBehaviour  BEHAVIOUR 

DEFINED  AS  --  inherited  from  Rec.  M.3100  Equipment,  with  the  following  extensions: 

!A  value  for  the  "Rec.  M.3100  :  1992": equipment  Id  attribute  can  only  be  provided  when  the  object  is 
created.    Furthermore,  this  attribute  value  may  not  change  once  the  managed  object  has  been 
instantiated.    Thus,  this  attribute  is  never  the  subject  of  an  AttributeValueChange  Notification. 

Conditions  under    which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted. 
All  attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter. 

The  process ingErrorA I arm  notification  (if  present)  is  emitted  when  the  Equipment  resource 
experiences  any  of  the  alarm  conditions  defined  by  ISO/IEC  10164-4  (e.g.,  storage  capacity  problem, 
version  mismatch,  corrupt  data,  software  error,  underlying  resource  unavailable).!; 

A.4.1.5  OMNIPoint  Network 

--  This  definition  is  subclassed  from  Rec.  M.3100  Network,  adding  the  following  items: 
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Network  Title  and  associated  nanie  binding  to  Root 
AttributeChange,  ObjectCreation,  ObjectDeletion  Notifications 
CREATE/DELETE  operations  and  behaviours  (in  name  bindings) 


opNetwork  MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  M.3100  :  1 992": network; 

CHARACTERIZED  BY  opNetworkPkg; 

REGISTERED  AS  <x-objectClass  5>; 


opNetworkPkg  PACKAGE 

BEHAVIOUR  opNetworkPkgBehaviour; 

--  opNetworkPkgOef inition  inherited  from  Rec.  M.3100  Network 

ATTRIBUTES 

networkTitle  GET; 

NOTIFICATIONS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":obiectCreation, 

"Rec.  X.721  ISO/IEC  10165-2  :  1992":objectDeletion, 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


opNetworkPkgBehaviour  BEHAVIOUR 

DEFINED  AS  --  inherited  from  Rec.  M.3100  Network,  with  the  following  extensions: 

lvalues  for  the  Network  Identifier  and  Network  Title  attributes  can  only  be  provided  when  the  object 
is  created.    Furthermore,  these  attribute  values  may  not  change  once  the  managed  object  has  been 
instantiated.    Thus,  they  are  never  the  subject  of  an  AttributeValueChange  Notification.  When 
NetworkTitle  is  used  for  naming,  the  Network  Identifier  attribute  has  a  NULL  value. 

Conditions  under  which  an  AttributeValueChange  Notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement  in  the  behaviour,  the 
attribute  does  not  cause  an  AttributeValueChange  notification  to  be  emitted.  All 
attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter.!; 


A.4.1.6  Processing  Entity 

process ingEntity  MANAGED  OBJECT  CLASS 

DERIVED  FROM  opEquipment; 
CHARACTERIZED  BY    process i ngEnt i tyPkg; 
CONDITIONAL  PACKAGES 

resource! , 
resource! , 

REGISTERED  AS    {x-objectClass  6>; 
process i ngEnt ityPkg  PACKAGE 


address ingPkg  PRESENT 
cpuUtilizationPkg  PRESENT 
memorySizePkg  PRESENT 
memoryUti lizationPkg  PRESENT 
upTimePkg  PRESENT 


IF  ! relevant  to  the  underlying 
IF  !an  instance  supports  it!, 
IF  'relevant  to  the  underlying 
IF  !an  instance  supports  it!, 
IF  !an  instance  supports  it!; 
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BEHAV I OUR  process i ngEnt  i  tyPkgDef  i  n i  t  i on, 
process  i  ngEnt  i  tyPkgBehavi  our ; 

ATTRIBUTES 

cpuType  PERMITTED  VALUES  SYNTAX- 1 .Graph icString16  GET, 

oslnfo  PERMITTED  VALUES  SYNTAX- 1 .OsInfoRange  GET;; 

process  i  ngEnt  i  tyPkgOef  i  ni  t  i  on  BEHAV I OUR 

DEFINED  AS 

!The  process i ngEnt ity  managed  object  class  represents  the  physical  portion  of  the  computer  system 
that    performs  a  processing  function,  frequently  called  a  Central  Processing  Unit  (CPU).  A 
Processing  Entity  may  be  composed  of  such  components  as  arithmetical  logical  units  (ALU), 
registers  for  processing  memory,  limited  storage  most  often  in  the  form  of  Random  Access  Memory 
(RAM),  and  various    other  types  of  memory  used  in  the  processing  fuiction.    It  does  not  include  such 
components  as  disk  drives,  data  bases,  etc. 

Some  Processing  Entities  may  have  input/output  channels,    particularly  when  hardware  is  shared 
between  elements   of  the  Processing  Entity.    In  other  cases,  the  input/output   must  be  seen  as 
components  of  a  superior  managed  object,  for    example  a  Computer  System,  or  as  OMNI  Point  Equipment 
objects  shared  among  several  Computer  Systems. 

The  cpuType  attribute  indicates  the  type  of  central  processor  unit  found  in  the  Processing  Entity. 

The  oslnfo  attribute  specifies  the  names  and  releases  of  the  supported  operating  systems.!; 
process i ngEnt i tyPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!The  AttributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  cpuType  or  oslnfo.!; 


A.4.1.7  Transport  Connection 

transportConnection  MANAGED  OBJECT  CLASS 

DERIVED  FROM    "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":  top; 

CHARACTERIZED  BY  transportConnectionPkg; 

CONDITIONAL  PACKAGES 

maxRet  ransmi  ss  i  onsPkg 
ret  r ansmi  ss  i  onT  i  mePkg 
ret  ransmi  ss  i  onT  i  mer  I  ni  t  i  a  I  Va  I  uePkg 
pdusRetransmittedCounterPkg 
octetsRet ransmi ttedPkg 
pdusRetransmittedThresholdPkg 
outgoingProtocolErrorPkg 
checksumPDUsD i scardedPkg 

REGISTERED  AS  Cx-objectClass  7>; 


transportConnectionPkg  PACKAGE 

BEHAVIOUR    t  ranspor tConnect  i  onPkgDef  i  ni  t  i  on, 
transportConnectionPkgBehaviour; 

ATTRIBUTES 

transportConnectionId  PERMITTED  VALUES  SYNTAX-1 .GraphicString64  GET, 
localTransportConnectionEndpoint  GET, 


PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

PRESENT 

IF 

■an  instance 

!an  instance 

!an  instance 

!an  instance 

!an  instance 

!an  instance 

!an  instance 

!an  instance 


supports  it! 
supports  it! 
supports  it! 
supports  it! 
supports  it! 
supports  it! 
supports  it! 
supports  it! 
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remoteTransportConnectionEndpoint  GET, 

transportConnectionReference   PERMITTED  VALUES  SYNTAX -1. I nteger32  GET, 
localNetworkAddress  GET, 
remoteNetworkAddress  GET, 

inactivityTimeout    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
inactivityTime  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
maxPOUSize    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":pdusSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusReceivedCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET, 
"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":octetsSentCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsReceivedCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992": inccmingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET; 


NOTIFICATIONS 
"Rec.  X.721 
"Rec.  X.721 
"Rec.  X.721 


ISO/IEC  10165-2  :  1992":objectCreation, 

ISO/IEC  10165-2  :  1992":obJectDeletion  transportDisconnectCause, 
ISO/IEC  10165-2  :  1992":attributeValueChange;; 


transportConnectionPkgDef inition  BEHAVIOUR 
DEFINED  AS 

[The  transportConnection  managed  object  class  represents  an  active  transport  connection  (e.g.,  an 
OSI  transport  connection  or  a  TCP  connection).    A  transport  connection  is  established  and  used  by 
two  peer  connection  oriented  transport  protocol  layer  entities  for  the  purpose  of  transferring  data. 
A  connection  oriented  transport  protocol  layer  entity  may  support  multiple  transport  connections. 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific 
connect  ion- oriented  transport  protocol;  rather  it  contains  characteristics  common  across  various 
different  connect  ion- oriented  transport  layer  protocols.    This  managed  object  class  is  not  intended 
to  override  any  transport  layer  managed  object  classes  defined  in  ISO.    It  provides  a  high  level 
view  of  a  connect  ion- oriented  transport  layer  protocol  and  complements  the  protocol -specific  views 
being  defined  in  the  standards.!; 


transportConnectionPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!An  instance  of  the  Transport  Connection  managed  object  class  is  created  automatically  in  response 
to  normal  operation  of  the  network.    A  prerequisite  to  the  creation  of  a  transport  connection  is  the 
existence  of  a  transport  entity  (e.g.  an  instance  of  the  Connection  Oriented  Transport  Protocol 
Layer  Entity)  on  the  open  system.  When  a  new  Transport  Connection  instance  is  created,  the  "0P1 
Library  Vol.  2  :  1992":transportConnectionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.    Alternatively,  the  Maximum  PDU  Size 
attribute  takes  on  the  value  of  the  Haxjmun  PDU  Size  attribute  specified  in  the  superior  Transport 
Protocol  Layer  Entity  managed  object  instance.  Subsequently  the  Maximum  PDU  Size  attribute  may  take 
on  another  value  which  applies  specifically  to  the  connection  represented  by  the  instantiation  of 
the  transport  connection.    This  change  may  occur  as  the  result  of  peer  protocol  negotiation. 

The  Additional  Information  parameter  of  the  objectDeletion  notification  may  optionally  contain  a 
management  extension  (as  defined  in  DMI)  whose  identifier  is  that  of  the  "cause"  attribute,  whose 
significance  is  FALSE,  and  whose  information  is  "cause"  as  defined  in  the  associated  PARAMETER 
template. 

Conditions  under  which  an  attributeValueChange  notification  is  emitted  are  stated  in  the  behaviour 
of  the  appropriate  package  or  attribute.    In  the  absence  of  such  a  statement,  in  the  behaviour,  the 
attribute  does  not  cause  an  attributeValueChange  to  be  emitted. 
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The  attributeValueChange  notification  is  emitted  when  any  of  the  following  attributes  change  in 
value:  inactivityTimeout,  maxPDUSize,  and  all  counter  attributes  (only  when  they  wrap).  All 
attributeValueChange  notifications  shall  include  the  Attribute  Identifier  List  parameter.  All 
attributeValueChange  notifications  which  report  counter  attribute  wraps  shall  contain  the  maximum 
counter  attribute  value  in  the  Old  Attribute  Value  parameter. 

Transport  Connection  will  delete  itself  when  the  value  of  the  inactivityTime  attribute  equals  that 
of  the  inactivityTimeout  attribute.!; 

This  is  a  generally  applicable  managed  object  class,  in  that  it  does  not  represent  any  specific  connection- 
oriented  transport  protocol.    ISO/IEC  10733  [TLH]  defines  specific  objects  for  managing  OSI  transport 
protocol  layer  entities. 

A.4.2  Conditional  Packages 


A.4.2.1  Addressing  Paclcage 

address ingPkg  PACKAGE 

BEHAVIOUR       address ingPkgDefi nit  ion, 
address i ngPkgBehavi our ; 

ATTRIBUTES     address ingSize     PERMITTED  VALUES  SYNTAX-1 .AddressingSizeRange  GET, 
endianess  GET; 
REGISTERED  AS  <:x-package  1>; 

address ingPkgDefi nit  ion  BEHAVIOUR 

DEFINED  AS 

!This  package  defines  the  addressing  size  and  endianess  which  are  characteristic  of  the  underlying 
resource. ! ; 

addressingPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  address ingSize  or  endianess  attributes  change 
value. ! ; 

A.4.2.2  Checksum  PDUs  Discarded  Package 

checksumPDUsDiscardedPkg  PACKAGE 

BEHAVI OUR    checksumPDUsD  i  scardedPkgDef  i  ni  t  i  on, 
checksumPDUsD  i  scardedPkgBehavi  our; 

ATTRIBUTES 

checksumPDUsDiscardedCounter  PERMITTED  VALUES  SYNTAX-1 .!nteger32  GET; 
REGISTERED  AS    Cx-package  2>; 


checksunPDUsD i scardedPkgDef i nit  ion  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  resource  to  count  the  nunber  of  well-formed 
PDUs  rejected  by  the  peer  entity  due  to  a  checksum  error.!; 


ch  ec  ksumPDUsD  i  sea  rdedPkgBeha v  i  our   BE  H AV I OUR 
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DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  checksunPDUsDiscarded  attribute  wraps. I; 

A.4.2.3  Contact  List  Package 

contactListPkg  PACKAGE 

BEHAVIOUR  contactListPkgDef inition, 
contactListPkgBehaviour; 

ATTRIBUTES     contactList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange    GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <x- package  3>; 

contactL  i  stPkgDef  i  ni  t  i  on   BEHAVI OUR 
DEFINED  AS 

!The  Contact  List  Attribute  identifies  who  (person  or  organization)  should  be  contacted  about  the 
resource. ! ; 

contactListPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  contactList  attribute  changes  value.!; 

A.4.2.4  Contact  Name  Package 

contactNamePkg  PACKAGE 

BEHAVIOUR  contactNamePkgDefinition, 
contactNamePkgBehaviour; 

ATTRIBUTES     contactName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  {x-.package  4>; 

contactNamePkgDefinition  BEHAVIOUR 
DEFINED  AS 

!The  Contact  Name  Attribute  identifies  who  (person  or  organization)  should  be  contacted  about  the 
resource. ! ; 

contactNamePkgBehaviour  BEHAVIOUR 

DEFINED  AS 

"If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  contactName  attribute  changes  value.!; 

A.4.2.5  CPU  Utilization  Package 

cpuUt  i I i  zat  i  onPkg  PACKAGE 
BEHAVIOUR      cpuUti I izationPkgBehaviour; 

ATTRIBUTES     cpuUti lization     PERMITTED  VALUES  SYNTAX- 1 .PercentageRange 

GET;  --    changed  from  GET-REPLACE  (Forum) 
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REGISTERED  AS  Cx-package  5>; 
cpuUtilizationPkgBehaviour  BEHAVICXJR 
DEFINED  AS 

lEven  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  NOT  emitted  when  the  cpuUti lization  attribute  changes  value. I; 

A.4.2.6  Customer  List  Package 

customerListPkg  PACKAGE 

BEHAVIOUR  customerListPkgDef inition, 
customerL  i  stPkgBehavi  our; 

ATTRIBUTES    customerList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  {x-package  6>; 

customerListPkgDef inition  BEHAVIOUR 

DEFINED  AS 

!The  Customer  List  attribute  identifies  any  customers  that   are  users  of  the  resource.!; 
customerL i StPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  customerList  attribute  changes  value.!; 

A.4.2.7  Customer  Name  Package 

customerNamePkg  PACKAGE 

BEHAVI OUR  customerNamePkgDef  i  ni  t  i on, 
customerNamePkgBehaviour; 

ATTRIBUTES    customerName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  7>; 

customerNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

!The  Customer  Name  attribute  identifies  any  customer  that  is  a  user  of  the  resource.!; 
customerNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  customerName  attribute  changes  value.!; 

A.4.2.8  Function  List  Package 

functionListPkg  PACKAGE 

BEHAVIOUR  functionListPkgDef inition, 
f unct  i  onL  i  stPkgBehavi  our; 

ATTRIBUTES  functionList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
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REGISTERED  AS  tx-package  8>; 
functionListPkgDefinition  BEHAVIOUR 
DEFINED  AS 

!The  functionList  attribute  identifies  those  functions    provided  by  this  resource.!; 
functionListPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  functionList  attribute  changes  value. I; 

A.4.2.9  Function  Name  Package 

functionNamePkg  PACKAGE 

BEHAVIOUR  functionNamePkgDef inition, 
f unct  i  onNamePkgBehavi  our ; 

ATTRIBUTES  functionName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  (x-package  9>; 

functionNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

!The  functionName  attribute  identifies  the  function  provided  by  this  resource.!; 
functionNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  functionName  attrilxite  changes  value.!; 

A.4.2.10  Incoming  Protocol  En'or  Package 

incomingProtocolErrorPkg  PACKAGE 

BEHAVIOUR    incomingProtocolErrorPkgDef inition, 
incomingProtocolErrorPkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992": incomingProtocolErrorCounter 

PER!*1ITTED  VALUES  SYNTAX- 1 .  Integer32  GET; 

REGISTERED  AS    {x-package  10>; 


incomingProtocolErrorPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  resource  to  count  the  nunber  of  incoming 
protocol  errors  detected.!; 


incomingProtocolErrorPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  incomingProtocolErrorCounter  attribute  wraps.!; 
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A.4.2.11  Location  Pointer  Paclcage 

locationPointerPkg  PACKAGE 

BEHAVIOUR     locationPointerPkgDef inition, 
locationPointerPkgBehaviour; 

ATTRIBUTES 

locationPointer  GET-REPLACE; 
REGISTERED  AS         <:x-package  11>; 


locationPointerPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  provides  managed  object  instance  information  for  a  location  (e.g.,  Hilo  Hawaii  USA). I; 


locationPointerPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Location  Pointer  attribute  changes  value. I; 


A.4.2.12  lUlanufacturer  List  Paclcage 

manufacturerListPkg  PACKAGE 

BEHAVI OUR     manuf acturerL  i  stPkgDef  i  ni  t  i  on, 
manuf acturerL  i  stPkgBehavi  our ; 

ATTRIBUTES 

manufacturerList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
REGISTERED  AS         Cx-package  12>; 


manuf acturerListPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  indicates  information  about  the  manuf acturer(s}  that  manufactured  the  underlying 
resource! ; 


manuf acturerL  i  stPkgBehavi  our  BEHAVI OUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  ManufacturerList  attribute  changes  value.!; 


A.4.2.13  IManufacturer  Name  Paclcage 

manufacturerNamePkg  PACKAGE 

BEHAVIOUR     manufacturerNamePkgDef inition, 
manuf acturerNamePkgBehavi our; 

ATTRIBUTES 

manufacturerName   PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS         {x-package  13>; 
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manufacturerNamePkgOef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  indicates  information  about  the  manufacturer  that  manufactured  the  underlying 
resource! ; 


manufacturerNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

llf  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  ManufacturerName  attribute  changes  value. I; 


A.4.2.14  Max  PDU  Size  IV  Package 


maxPDUSizelVPkg  PACKAGE 

BEHAVIOUR     maxPDUSizelVPkgOef inition, 
maxPDUSizelVPkgBehaviour; 

ATTRIBUTES 

maxPDUSize    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET-REPLACE; 
REGISTERED  AS  (x-package  U>; 


maxPDUS  i  ze I VPkgDef  i  n i  t  i  on  BE  HAV I OUR 
DEFINED  AS 

IThis  package  provides  the  initial  value  for  the  maximum  length  of  a  PDU  that  can  be  supported  by 
the  local  layer  entity.!; 

maxPDUSizelVPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Maximum  TPDU  Size  attribute  provides  the  initial  value  to  be  used  by  newly- instantiated 
subordinate  Transport  Connection  managed  object  instances  for  the  maximun  TPDU  size  to  be  supported 
on  that  connection.!; 


A.4.2.15  Max  Retransmissions  Package 


maxRetransmissionsPkg  PACKAGE 

BEHAVIOUR    maxRet ransmi  ss  i  onsPkgDef  i  ni  t  i  on, 
maxRet ransmi  ss  i  onsPkgBehavi  our; 

ATTRIBUTES 

maxRet ransmi ss ions    PERMITTED  VALUES  SYNTAX-1 .Integer32  GET; 
REGISTERED  AS    <x-package  15>; 


maxRetransmi  ssi  onsPkgDef  i  ni  t  i  on  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
maximun  nunber  of  times  a  TPDU  is  to  be  retransmitted  before  the  transport  connection  is  aborted. I; 


maxRetransmi ssionsPkgBehavi our  BEHAVIOUR 
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DEFINED  AS 

lUhen  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "OPI  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVMO  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.!; 

A.4.2.16  Memory  Size  Package 

memorySizePkg  PACKAGE 

BEHAVIOUR  memorySizePkgDef inition, 

memoryS i zePkgBehavi our ; 

ATTRIBUTES     memorySize     PERMITTED  VALUES  SYNTAX- 1 .MemoryS izeRange  GET; 

REGISTERED  AS  Cx-package  16>; 

memorySizePkgOef inition  BEHAVIOUR 

DEFINED  AS 

IThe  memorySize  attribute  indicates,  in  kilobytes,  the  amount  of  memory  available  to  a  Processing 
Entity  (irrespective  of  its  current  usage).!; 

memorySizePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!lf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  memoiySize  attribute  changes  value.!; 

A.4.2.17  Memory  Utilization  Package 

memoryUt  i I i  zat  i  onPkg  PACKAGE 

BEHAVIOUR      memoryUti I izationPkgBehaviour; 

ATTRIBUTES     memoryUti I izati on     PERMITTED  VALUES  SYNTAX- 1 .PercentageRange 

GET;        added  in  response  to  Bull  conment 

REGISTERED  AS  Cx-package  17>; 

memoryUti I izationPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

!Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  NOT  emitted  when  the  memoryUt i I i zat i on  attribute  changes  value.!; 

A.4.2.18  Octets  Retransmitted  Package 

octetsRetransmittedPkg  PACKAGE 

BEHAVIOUR    octetsRetransmittedPkgDef inition, 
octetsRetransmittedPkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":octetsRetransmittedErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    {x-package  18>; 


OctetsRetransmittedPkgDef inition  BEHAVIOUR 
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DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
number  of  octets  retransmitted.); 


octetsRetransmittedPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  octetsRetransmitted  attribute  wraps. I; 


A.4.2.19  OMNIPoint  NetwcM-k  Ust  Package 

opNetworkListPkg  PACKAGE 

BEHAVIOUR  opNetworkListPkgDefinition, 
opNetworkL  i  stPkgBehavi  our; 

ATTRIBUTES    opNetworkList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  (x-package  19>; 

opNetworkListPkgDefinition  BEHAVIOUR 


DEFINED  AS 

!The  opNetworkList  attribute  indicates  what  networks  use  or  are  dependent  on  the  resource.!; 
opNetworkL i StPkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  opNetworkList  attribute  changes  value.!; 


A.4.2.20  OMNIPoint  Network  Name  Package 

opNetworkNamePkg  PACKAGE 

BEHAVIOUR  opNetworkNamePkgDefinition, 
opNetworkNamePkgBehaviour; 

ATTRIBUTES    opNetworkName    PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  {x-package  20>; 

opNetworkNamePkgDefinition  BEHAVIOUR 


DEFINED  AS 

!The  opNetworkName  attribute  indicates  what  network  uses  or  is  dependent  on  the  resource.!; 
OpNetworkNamePkgBehaviour  BEHAVIOUR 
i   DEFINED  AS 

'  ilf  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 

package,  this  notification  is  emitted  when  the  opNetworkName  attribute  changes  value.!; 


A.4.2.21  OMNIPoint  Version  Package 
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opVersionPkg    PACKAGE    --  refinement  of  Rec.  H.3100  versionPackage 

BE  HAV I OUR     opVers  i  onPkgDef  i  ni  t  i  on , 
opVers i oN'kgBehavi our; 

ATTRIBUTES 

"Rec.  M.3100  :  1992":version 

PERMITTED  VALUES  SYNTAX-1 .GraphicString16  GET-REPLACE; 

REGISTERED  AS    {x-package  21>; 


opVersionPkgDef inition  BEHAVIOUR 
DEFINED  AS 

■This  package  reflects  the  release  version  of  the  underlying  resource  as  an  attribute,  as  defined  by 
"Rec.  M.3100  :  1992".!; 


opVersionPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Version  attribute  changes  value.!; 


A.4.2.22  Outgoing  Protocol  Error  Package 

outgoingProtocolErrorPkg  PACKAGE 

BEHAVIOUR    outgoingProtocolErrorPkgDef inition, 
outgoingProtocolErrorPkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":outgoingProtocolErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    Cx-package  22>; 


OutgoingProtocolErrorPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  resource  to  count  the  number  of  outgoing 
protocol  errors  detected.    Note  that  not  all  resources  have  this  capability.!; 


outgoingProtocolErrorPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  outgoingProtocolErrorCounter  attribute  wraps.!; 

A.4.2.23  PDUs  Retransmitted  Counter  Package 

pdusRetransmittedCounterPkg  PACKAGE 

BEHAVIOUR    pdusRetransmittedCounterPkgDef inition, 
pdusRetransmittedCounterPkgBehaviour; 
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ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":pdusRetransinittedErrorCounter 

PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 

REGISTERED  AS    <x- package  23>; 


pdusRetransmittedCounterPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  count  the 
nunber  of  PDUs  retransmitted.!; 


pdusRetransmittedCounterPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

•If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  PDUsRetransmittedCounter  attribute  wraps.!; 


A.4.2.24  PDUs  Retransmitted  Threshold  Package 

pdusRetransmittedThresholdPkg  PACKAGE 

BEHAVIOUR    pdusRetransmittedThresholdPkgDef inition, 
pdusRet  ransmi  t  tedTh  resho I dPkgBehavi  our ; 

ATTRIBUTES 

"Rec.  X.721  I  ISO/IEC  10165-2- :  1992":pdusRetransmittedErrorThreshold  GET-REPLACE; 
NOTIFICATIONS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":coninunicationsAlarm; 
REGISTERED  AS    <:x-package  24>; 


pdusRet ransmi ttedThresholdPkgDef inition  BEHAVIOUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  threshold  the 
number  of  PDUs  retransmitted.!; 


pdusRet  ransmi  t tedTh  resho I dPkgBehavi  our   BE  HAV I OUR 
DEFINED  AS 

!When  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "OPI  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance. 

If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this  package, 
this  notification  is  emitted  when  the  pdusRetransmittedThreshold  attribute  changes  in  value.!; 


A.4.2.25  Peripheral  List  Package 

peripheral  istPkg  PACKAGE 

BEHAVIOUR     per ipheralListPkgDef inition, 
per  i  phera I L  i  stPkgBehavi  our; 

ATTRIBUTES 
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peripheralList    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
REGISTERED  AS  <x-package  25>; 

per i phera I L i s tPkgDef  i ni  t  i on  BE HAVI OUR 
DEFINED  AS 

I  The  Peripheral  List  attribute  identifies  auxiliary  devices  that  are  used  by  the  resource  (e.g., 
disk  drives,  tape  drives,  printers). I ; 

peripheralListPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Peripheral  List  attribute  changes  value.!; 

A.4.2.26  Peripheral  Name  Package 

peripheralNamePkg  PACKAGE 

BEHAVIOUR     peripheralNamePkgDef inition, 
per  i  phera I NamePkgBehavi  our ; 

ATTRIBUTES 

peri phera I Name   PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS  <x-package  26>; 

per { phera I NamePkgDef  i ni  t  i  on  BE HAV I OUR 
DEFINED  AS 

!The  Peripheral  Name  attribute  identifies  an  auxiliary  device  that  is  used  by  the  resource  (e.g., 
disk  drive,  tape  drive,  printer).!; 

peri phera I NamePkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Peripheral  Name  attribute  changes  value.!; 

A.4.2.27  Processing  Entity  List  Package 

process ingEntityListPkg  PACKAGE 

BEHAVIOUR     processingEntityListPkgDef inition, 
process  i  ngEnt  i  tyL  i  stPkgBehavi  our; 

ATTRIBUTES 

processi ngEnt i tyL ist    PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 
REGISTERED  AS  <x-package  27>; 

process i ngEnt i  tyL i stPkgDef  i ni  t i on  BEHAVIOUR 
DEFINED  AS 
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!The  Processing  Entity  List  attribute  identifies  the  processing  entities  which  may  be  used  by  the 
containing  object  instance  but  which  are  not  contained  in  it  (i.e.,  processing  entities  which  are 
shared  among  systems).!; 


process i ngEnt  i  tyL i stPkgBehavi our  BEHAVI OUR 
DEFINED  AS 

I  If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Processing  Entity  List  attribute  changes  value. I; 


A.4.2.28  Processing  Entity  Name  Pacl(age 

process i ngEnt ityNamePkg  PACKAGE 

BEHAV I OUR     process  i  ngEnt  i  tyNamePkgDef  i  ni  t  i  on, 
process  i  ngEnt  i  tyNamePkgBehavi  our ; 

ATTRIBUTES 

process i ngEnt ityName   PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 
REGISTERED  AS         Cx-package  28>; 


process  i  ngEnt  i  tyNamePkgDef  i  n i  t  i  on  BE  HAV I OUR 
DEFINED  AS 

!The  Processing  Entity  Name  attribute  identifies  the  processing  entity  which  may  be  used  by  the 
containing  object  instance  but  which  is  not  contained  in  it  (i.e.,  processing  entities  which  are 
shared  among  systems).!; 


process i ngEnt i tyNamePkgBehavi our  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Processing  Entity  Name  attribute  changes  value.!; 


A.4.2.29  Product  l^bel  Paclcage 


product Labe I Pkg  PACKAGE 

BEHAVIOUR     productLabelPkgDef inition, 
productLabelPkgBehaviour; 

ATTRIBUTES 

productLabel    PERMITTED  VALUES  SYNTAX-1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS         Cx-package  29>; 


productLabelPkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  allows  the  product  nunfcer  or  identifying  string  (e.g.,  model  number)  of  the  underlying 
resource  to  be  reflected  as  an  attribute.!; 


productLabelPkgBehaviour  BEHAVIOUR 
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DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Product  Label  attribute  changes  value.!; 


A.4.2.30  Retransmission  Time  Paclcage 

retransmissionTimePkg  PACKAGE 

BEHAVIOUR    retransmissionTimePkgDef inition, 
ret  ransmi  ss  i  onT  imePkgBehavi  our; 

ATTRIBUTES 

ret ransmi ssionTi me  PERMITTED  VALUES  SYNTAX- 1. I nteger32  GET; 
REGISTERED  AS    {x-package  30>; 
ret  ransmi  ss  i  onT  i  mePkgDef  i  ni  t  i  on   BE  HAV I OUR 
DEFINED  AS 

IThis  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  present  its 
current  retransmission  timer  value  as  an  attribute.!; 


ret  ransmi  ss  i  onT  i  mePkgBehavi  our    BEHAV I OUR 
DEFINED  AS 

!When  a  new  Transport  Connection  instance  is  created  containing  this  package,  the  initial  value  of 
this  attribute  may  be  provided  by  the  retransmissionTimerlnitialValue  attribute  (if  present  in  the 
new  managed  object  instance).!; 


A.4.2.31  Retransmission  Timer  Initial  Value  Package 


ret  ransmi  ss  i  onT  i  mer I n  i  t  i  a I Va I ueP  kg  PACIMGE 

BE  HAV I OUR    ret  r ansm  i  ss  i  onT  i  mer I n  i  t  i  a I Va I ueP  kgO  ef  i  n  i  t  i  on , 
ret  ransmi  ss  i  onT  i  mer I ni  t  i  a  I Va I uePkgBehav  i  our ; 

ATTRIBUTES 

retransmissionTimerlnitialValue  PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS    Cx-package  31>; 

ret  ransmi  ss  i  onT  i  mer I n  i  t  i  a  I Va I uePkgDef  i  ni  t  i  on   BEHAVI OUR 
DEFINED  AS 

!This  package  reflects  the  capability  of  the  underlying  transport  protocol  resource  to  present  its 
initial  retransmission  timer  value  as  an  attribute.!; 


retransmissionTimerlnitialValuePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!When  a  new  Transport  Connection  instance  is  created  containing  this  package,  any  "OPI  Library  Vol. 
2  :  1992":transportConnectionRetransmissionIVM0  instance  with  the  same  superior  may  be  used  to 
provide  initial  attribute  values  for  the  new  instance.!; 
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A.4.2.32  Serial  Number  Package 

serialNunberPkg  PACKAGE 

BEHAVIOUR  serialNumberPkgOefinition. 

sen  i  a  I NumberPkgBehavi  our ; 

ATTRIBUTES 

serialNunber     PERMITTED  VALUES  SYNTAX-1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS  Cx-package  32>; 

serialNumberPkgDef jnition  BEHAVIOUR 
DEFINED  AS 

IThis  package  allows  the  serial  nunber  of  the  underlying  resource  to  be  reflected  as  an  attribute. I ; 

serialNumberPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Serial  Number  attribute  changes  value. I ; 

A.4.2.33  Service  List  Pacl(age 

serviceListPkg  PACKAGE 

BEHAVIOUR  servi ceL i stPkgDef  i ni  t i on, 
serviceListPkgBehaviour; 

ATTRIBUTES     serviceList     PERMITTED  VALUES  SYNTAX-1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <:x-package  33>; 

servi ceLi StPkgDef i nit  ion  BEHAVIOUR 

DEFINED  AS 

! Service  List  attribute  identifies  any  services  that    are  supported  by  the  resource.!; 
serviceListPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

I  If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  serviceList  attribute  changes  value.!; 

A.4.2.34  Service  Name  Paclcage 

servi ceNamePkg  PACKAGE 

BEHAVIOUR  servi ceNamePkgDefi nit  ion, 
servi  ceNamePkgBehavi  our; 

ATTRIBUTES     serviceName     PERMITTED  VALUES  SYNTAX-1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  Cx-package  34>; 

servi CeNamePkgDefi nit  ion  BEHAVIOUR 
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DEFINED  AS 

iService  Name  attribute  identifies  any  service  that  is  supported  by  the  resource.!; 
serviceNamePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  serviceName  attribute  changes  value. I; 

A.4.2.35  Software  List  Package 

softwareListPkg  PACKAGE 

BEHAVI OUR  sof twareL i stPkgDef  i ni  t i on, 
softwareListPkgBehaviour; 

ATTRIBUTES    softwareList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  <x-package  35>; 

softuareListPkgDef inition  BEHAVIOUR 

DEFINED  AS 

!The  Software  List  attribute  identifies  those  software  components  that  run  on  or  are  considered  part 
of  the  resource. ! ; 

sof twareL  i  stPkgBehavi  our    BEHAVI OUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  softwareList  attribute  changes  value.!; 

A.4.2.36  Software  Name  Package 

softwareNamePkg  PACKAGE 

BEHAVI OUR  sof twareNamePkgDef  i ni  t i on, 
sof twareNamePkgBehaviour; 

ATTRIBUTES    softwareName  PERMITTED  VALUES  SYNTAX- 1 .AnyNameRange  GET-REPLACE; 

REGISTERED  AS  €x-package  36>; 

softwareNamePkgDef inition  BEHAVIOUR 

DEFINED  AS 

■The  Software  Name  attribute  identifies  the  software  component  that  runs  on  or  are  considered  part 
of  the  resource.!; 

sof twareNamePkgBehaviour  BEHAVIOUR 

DEFINED  AS 

■If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  softwareName  attribute  changes  value.!; 

A.4.2.37  System  Time  Package 

systemTimePkg  PACKAGE 

BE  H AV I OUR     sys  t  emT  i  meP  kgDef  i  n  i  t  i  on , 
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syStemTimePkgBehaviour; 

ATTRIBUTES 

systemTime   PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS  {x-package  37>; 


systemTimePkgDef inition  BEHAVIOUR 
DEFINED  AS 

IThis  package  records  the  current  time  clocked  by  the  resource. I; 


systemTimePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!The  attribute  contained  in  this  package  is  never  the  subject  of  an  attribute  value  change 
notification.    Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class 
using  this  package,  this  notification  is  NOT  emitted  when  the  systemTime  attribute  changes  value.!; 


A.4.2.38  Type  Text  Package 


typeTextPkg  PACKAGE 

BEHAVIOUR     typeTextPkgDef inition, 
typeTextPkgBehaviour; 

ATTRIBUTES 

typeText     PERMITTED  VALUES  SYNTAX- 1 .GraphicString32  GET-REPLACE; 
REGISTERED  AS  Cx-package  38>; 


typeTextPkgDef inition  BEHAVIOUR 
DEFINED  AS 

(This  package  serves  to  supplement  and  refine  individual  managed  object  class  attributes!; 


typeTextPkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  attributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  Type  Text  attribute  changes  value.!; 


A.4.2.39  Up  Time  Package 

upTimePkg  PACKAGE 

BEHAVIOUR  upTimePkgDefinition, 
upT  imePkgBehavi  our; 

ATTRIBUTES 

upTime    PERMITTED  VALUES  SYNTAX- 1 . Integer32  GET; 
REGISTERED  AS  Cx-package  39>; 
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upTitnePkgDefinition  BEHAVIOUR 
DEFINED  AS 

IThis  package  records  the  elapsed  time  during  which  the  underlying  resource  has  been  enabled.!; 


upTimePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!The  attribute  contained  in  this  package  is  never  the  subject  of  an  attribute  value  change 
notification.    Even  if  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class 
using  this  package,  this  notification  is  NOT  emitted  when  the  upTime  attribute  changes  value.!; 


A.4.2.40  Usage  State  Package 


usageStatePkg  PACKAGE 

BEHAVIOUR     usageStatePkgDef inition, 
usageStatePkgBehaviour; 

ATTRIBUTES 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":usageState  GET; 

ATTRIBUTE  GROUPS 

"Rec,  X.721  I  ISO/IEC  10165-2  :  1992":state 

"Rec.  X.721  j  ISO/IEC  10165-2  :  1992":usageState; 

REGISTERED  AS  {x-package  40>; 


usageStatePkgDef  i  ni  t  i  on   BEHAVI OUR 
DEFINED  AS 

I  This  package  specifies  the  Usage  State  of  the  underlying  resource,  to  be  included  in  resources 
which  are  able  to  detect  whether  or  not  they  are  currently  in  use.!; 


UsageStatePkgBehaviour  BEHAVIOUR 
DEFINED  AS 

!If  the  stateChange  notification  is  defined  for  the  managed  object  class  using  this  package, 
this  notification  is  emitted  when  the  usageState  attribute  changes  value.!; 


A.4.2.41  Vendor  List  Package 

vendorListPkg  PACKAGE 

BEHAVIOUR  vendorListPkgDef inition, 
vendorL  i  stPkgBehavi  our; 

ATTRIBUTES    vendorList  PERMITTED  VALUES  SYNTAX- 1 .AnyNamesRange  GET-REPLACE  ADD-REMOVE; 

REGISTERED  AS  {x-package  41>; 


vendorL  i  stPkgDef  i  ni  t  i  on  BEHAVI OUR 
DEFINED  AS 
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IThe  VeixJor  List  attribute  identifies  the  organization(s)  from  which  the  resource  was  obtained 
(e.g.,  purchased,    leased,  etc.)!; 

vendorListPkgBehaviour  BEHAVIOUR 

DEFINED  AS 

!If  the  AttributeValueChange  notification  is  defined  for  the  managed  object  class  using  this 
package,  this  notification  is  emitted  when  the  vendorList  attribute  changes  value. I; 


A.4.3  Name  Bindings 

A.4.3.1  Computer  System  Name  Bindings 

computerSystem-system  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":system; 
WITH  ATTRIBUTE  computerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <x-nameBinding  1>; 


computerSystem- opNetwork  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        opNetwork  AND  SUBCLASSES; 
WITH  ATTRIBUTE  computerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  2>; 


computerSystem-computerSystem      NAME  BINDING 
SUBORDINATE  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  computerSystemId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE  ONLY-IF-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  3>; 

A.4.3.2  CO  Transport  Protocol  Layer  Entity  Name  Bindings 

coTransportProtocolLayerEntity-computerSystem   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEntityld; 
REGISTERED  AS    <x-nameBinding  4>; 

coTransportProtocolLayerEntity-system   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  system  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEntityld; 
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REGISTERED  AS    Cx-nameBinding  5>; 

coTransportProtocolLayerEntity-opEquipment    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
WITH  ATTRIBUTE  coTransportProtocolLayerEnti tyld; 
REGISTERED  AS    <x-naineBinding  6>; 


A.4.3.3  CL  Network  Protocol  Layer  Entity  Name  Bindings 

clNetworkProtocolLayerEntity-cofnputerSystem   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetworkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  computerSystefli  AND  SUBCLASSES; 
WITH  ATTRIBUTE  clNetworkProtocolLayerEntityld; 
REGISTERED  AS    <x-nameBinding  7>; 

clNetworkProtocolLayerEntity-system   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetworkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  system  AND  SUBCLASSES; 
WITH  ATTRIBUTE  ClNetworkProtocolLayerEntityld; 
REGISTERED  AS    Cx-nameBinding  8>; 

ClNetworkProtocolLayerEntity- opEquipment    NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  clNetworkProtocolLayerEntity  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
WITH  ATTRIBUTE  ClNetworkProtocolLayerEntityld; 
REGISTERED  AS    Cx-nameBinding  9>; 

A.4.3.4  OIUINIPoint  Equipment  Name  Bindings 

opEquipment-computerSystem  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    computerSystem  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M,3100  :  1992":equipmentld; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <;x-nameBinding  10>; 

opEquipment -system  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":system; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":equipmentld; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  11>; 

opEquipment -equipment  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  M.3100  :  1992": equipment  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992": equipment  Id; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC- INSTANCE-NAMING; 
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DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  {x-nameBinding  12>; 

opEquipment-opNetwork  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opEquipment  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS        opNetwork  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":equipntentld; 

CREATE    WITH-REFERENCE-OBJECT,  UITH-AUTOHATIC-INSTANCE-NAHING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  <x-nameBinding  13>; 

A.4.3.5  OMNIPoint  Network  Name  Bindings 

--  The  following  name  bindings  are  defined,  in  addition  to  those 

--  inherited  from  Rec.  M.3100  Network  (which  do  not  include  CREATE/DELETE): 

network-opNetwork-1  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS    "Rec.  M.3100  :  1992":network  AND  SUBCLASSES; 
WITH  ATTRIBUTE    "Rec.  M.3100  :  1992":networkId; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC-INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  {x-nameBinding  14>; 


network-opNetwork-2         NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "Rec.  M.3100  :  1992":network  AND  SUBCLASSES; 
WITH  ATTRIBUTE  networkTitle; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC-INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  15>; 


opNetwork- root  NAME  BINDING 

SUBORDINATE  OBJECT  CLASS    opNetwork  AND  SUBCLASSES; 

NAMED  BY  SUPERIOR  OBJECT  CLASS  "Rec.  X.660  |  ISO/IEC  9834-1  :  1992":root; 
WITH  ATTRIBUTE  networkTitle; 

CREATE    WITH-REFERENCE-OBJECT,  WITH-AUTOMATIC-INSTANCE-NAMING; 

DELETE    ONLY- I F-NO-CONTAINED-OBJECTS; 

REGISTERED  AS  Cx-nameBinding  16>; 


A.4.3.6  Processing  Entity  Name  Bindings 

--  process ingEntity- opEquipment  NAME  BINDING 
--  process ingEntity- computer System  NAME  BINDING 

--  both  inherited  from  opEquipment,  no  additional  bindings  required. 


A.4.3.7  Transport  Connection  Name  Bindings 

transportConnection-coTransportProtocolLayerEntity   NAME  BINDING 
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SUBORDINATE  OBJECT  CLASS  transportConnection  AND  SUBCLASSES; 
NAHED  BY 

SUPERIOR  OBJECT  CLASS  coTransportProtocolLayerEntity  AND  SUBCLASSES; 
UITH  ATTRIBUTE  transportConnectionId; 
BE HAV I OUR  t  ranspor t Connec t  i  onNBBeh avi  our ; 
DELETE  DELETES-CONTAINED-OBJECTS; 
REGISTERED  AS    Cx-nameBinding  17>; 


transportCormectionNBBehaviour  BEHAVIOUR 
DEFINED  AS 

I  The  expected  real  effect  of  the  DELETE  operation  when  applied  to  an  instance  of  the  transport 
connection  managed  object  class  is  that  the  underlying  transport  connection  resource  is  aborted.!; 


A.4.4  Attributes 

A.4.4.1  Active  Connections 

activeConnections  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  activeConnectionsBehaviour; 

REGISTERED  AS        Cx-attribute  1>; 

ac  t  i  veConnec  t  i  onsBeh  av  i  our     BE  HAV I OUR 

DEFINED  AS 

!The  activeConnections  attribute  specifies  the  number  of  currently  active  transport  connections 
(i.e.,  the  nunijer  of  transport  connections  which  are  in  the  open  state  [as  defined  for  the 
underlying  protocol  machine],  updated  upon  each  connection  establishment  and  release).!; 


A.4.4.2  Addressing  Size 

address ingSize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Address ingSizeBase; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR    address ingSizeBehavi our; 

REGISTERED  AS  {x-attribute  2>; 

address ingSizeBehavi our  BEHAVIOUR 

DEFINED  AS 

!The  Addressing  Size  attribute  indicates  the  number  of  bits  which  represent  an  address  to  the 
Processing  Entity's  central  processing  unit  (CPU).!; 


A.4.4. 3  Checksui  PDUs  Discarded  (Uiunter 

checksumPDUsDiscardedCounter  ATTRIBUTE 
DERIVED  FROM 

"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    checksumPDUsD  i  scardedCounterBehavi  our; 
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REGISTERED  AS        Cx-attribute  3>; 

checksunPDUsD  i  scardedCount erBehav  i  our     BE  HAVI OUR 

DEFINED  AS 

!The  attribute  specifies  the  nunber  of  well-formed  PDUs  rejected  by  the  peer  entity  due  to  a 
checksum  error. I ; 

A.4.4.4  Computer  System  Id 

cotnputerSystemld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 
HATCHES  FOR    EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  computerSystemldBehaviour; 

REGISTERED  AS        {x-attribute  4>; 

computerSystemldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  computerSystemId  attribute  is  the  distinguishing  attribute  for  the  computerSystem  managed 
object  class. ! ; 

A.4.4.5  CL  Network  Protocol  Layer  Entity  Id 

clNetworkProtocol LayerEnt  i  tyld   ATTR I  BUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 . GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BEHAVIOUR    c INetworkProtocol LayerEnt  i  tyldBehavi  our; 

REGISTERED  AS        Cx-attribute  5>; 

clNetworkProtocolLayerEntityldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  clNetworkProtocolLayerEntityld  attribute  is  the  distinguishing  attribute  for  the 
clNetworkProtocolLayerEntity  managed  object  class.!; 

A.4.4.6  CO  Transport  Protocol  Layer  Entity  Id 

coTransportProtocol LayerEnt ityld  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  coTransportProtocolLayerEntityldBehaviour; 

REGISTERED  AS        {x-attribute  6>; 

coTransportProtocol LayerEnt i tyldBehavi our  BEHAVIOUR 

DEFINED  AS 

!The  coTransportProtocolLayerEntityld  attribute  is  the  distinguishing  attribute  for  the 
coTransportProtocolLayerEntity  managed  object  class.!; 

A.4.4.7  Contact  List 

contactList  ATTRIBUTE 
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WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  contactListBehaviour; 

REGISTERED  AS  tx-attribute  7>; 

contactListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Contact  List  attribute  provides  managed  object  instance  information  for  one  or  more  contacts. 
The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
contacts:  "0P1  Library  Vol.  4":Contact. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.8  Contact  Name 

contactName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  contactNameBehaviour; 

REGISTERED  AS  <x-attribute  8>; 

contactNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Contact  Name  attribute  provides  information  for  one  person  or  organization  who  can  be 
contactacted  about  the  resource. I ; 

A.4.4.9  CPU  Type 

cpuType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  cpuTypeBehaviour; 

REGISTERED  AS  €x-attribute  9>; 

cpuTypeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Central  Processor  Unit  (CPU)  Type  attribute  indicates  the  type  of  central  processor  unit  found 
in  a  Processing  Entity.!; 

A.4.4.10  CPU  Utilization 

cpuUtilization  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 . IntegerBase; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  cpuUtilizationBehaviour; 

REGISTERED  AS  Cx-attribute  10>; 

cpuUt  i I i  zat  i  onBehavi  our  BEHAVI OUR 

DEFINED  AS 
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!The  cpUUtilizatioh  attribute  specifies,  as  a  percentage,  the  overall  utilization  of  all  central 
processor  units  found  in  a  processing  entity.    The  percentage  is  expressed  as  an  integer  with 
permissible  values  in  the  range  of  0  to  100.1; 

A.4.4.11  Customer  List 

customerList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
HATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  customerListBehaviour; 

REGISTERED  AS  {x-attribute  11>; 

customerListBehavi.our  BEHAVIOUR 

DEFINED  AS 

!The  Customer  List  attribute  provides  managed  object  instance  information  about  one  or  more 
customers.    The  following  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
customers:  "0P1  Library  Vol.  4":Customer. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. I; 

A.4.4.12  Customer  Name 

customerName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  customerNameBehaviour; 

REGISTERED  AS  {x-attribute  12>; 

customerNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Customer  Name  attribute  provides  information  about  one  customer.!; 

A.4.4.13  Endianess 

endianess  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Endianess; 
MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  endianessBehaviour; 

REGISTERED  AS  <x-attribute  13>; 

endianessBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Endianess  attribute  indicates  the  bit  order  (big  endian,  little  endian)  used  by  the  Processing 
Entity's  central  processing  unit  (CPU),!; 


A.4.4.14  Function  List 

functionList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 
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MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  functionListBehaviour; 

REGISTERED  AS  Cx-attribute  14>; 

functionListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  Function  List  attribute  provides  managed  object  instance  information  about  one  or  more 
functions.    The  following  managed  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes) 
are  valid  as  functions:    "0P1  Library  Vol.  4": Function. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. I; 

A.4.4.15  Function  Name 

functionName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  functionNameBehaviour; 

REGISTERED  AS  <x-attribute  15>; 

functionNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Function  Name  attribute  provides  information  about  one  function.!; 

A.4.4.16  Inactivity  Time 

inactivityTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BE  HAV I OUR    i  nac t  i  vi  tyT  i  meBehav  i  our ; 

REGISTERED  AS  Cx-attribute  16>; 

i nac t  i  vi  tyT  i meBeh aviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  amount  of  time  (in  1/IOOths  of  a  second)  that  the  transport  connection 
has  been  inactive.!; 

A.4.4.17  Inactivity  Timeout 

inactivityTimeout  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .HundredthsOf Sec; 

MATCHES  FOR      EQUALITY,  ORDERING; 

BE HAV I OUR    i  nact  i  vi  tyT  imeoutBehavi  our; 

REGISTERED  AS  Cx-attribute  17>; 

inactivityTimeoutBehaviour  BEHAVICXJR 

DEFINED  AS 
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IThis  attribute  specifies  the  maximum  amount  of  time  (in  l/IOOths  of  a  second)  that  the  transport 
connection  can  remain  enabled  when  there  is  no  activity  (i.e.,  data  flow  )  on  it.    A  value  of  0  for 
this  attribute  indicates  that  an  inactivity  timeout  is  not  supported  on  the  transport  connection. I ; 

A.4.4.18  Local  Network  Address 

localNetworkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .Address; 
MATCHES  FOR       EQUALITY,  SUBSTRINGS; 
BEHAVICXJR  localNetworkAddressBehaviour; 

REGISTERED  AS         <x-attribute  18>; 

localNetworkAddressBehaviour  BEHAVICXJR 

DEFINED  AS 

!The  localNetworkAddress  attribute  identifies  the  local  network  address  supported  by  a  network 
protocol  layer  entity  (e.g.,  local  IP  address  for  TCP  or  the  local  NSAP  address  for  OSI).!; 

A.4.4.19  Local  Network  Addresses 

localNetworkAddresses  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX       SYNTAX- 1 .NetworkAddresses; 
MATCHES  FOR      SET -COMPARISON,  SET- INTERSECTION; 
BEHAV I OUR    I oca  I Networ kAddressesBehav i  our ; 

REGISTERED  AS  Cx-attribute  19>; 

I  oca I NetworkAddressesBehavi  our     BEHAV I OUR 

DEFINED  AS 

IThe  localNetworkAddresses  attribute  identifies  the  local  network  addresses  supported  by  a  network 
protocol  layer  entity  (e.g.,  local  IP  address  for  TCP  or  the  local  NSAP  address  for  OSI). 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.20  Local  Transport  Addresses 

localTransportAddresses  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .TransportAddresses; 
MATCHES  FOR      SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  localTransportAddressesBehaviour; 

REGISTERED  AS    Cx-attribute  20>; 

localTransportAddressesBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  localTransportAddresses  attribute  specifies  the  set  of  local  transport  addresses  (e.g,  local 
TSAP  identifiers)  that  a  connection  oriented  transport  protocol  layer  entity  provides  to  its  users. 
A  transport  address  consists  of  a  transport  connection  endpoint  and  a  network  address. 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute.!; 

A.4.4.21  Local  Transport  Connection  Endpoint 
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localTransportCormectionEndpoint  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .Address; 

MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  localTransportConnectionEndpointBehaviour; 

REGISTERED  AS         {x-attn'bute  21>; 

localTransportComectionEndpointBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  identifies  the  local  transport  connection  endpoint  (e.g.,  the  source  port  for  TCP  or 
the  local  t-selector  for  OSI  Transport  protocol). I; 

A.4.4.22  Location  Pointer 

locationPointer  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .Objectlnstance; 

MATCHES  FOR  EQUALITY; 

BEHAVIOUR  locationPointerBehaviour; 

REGISTERED  AS  Cx-attribute  22>; 

I ocat  i  onPoi  nterBehavi  our  BEHAVI OUR 

DEFINED  AS 

IThe  Location  Pointer  attribute  provides  managed  object  instance  information  for  a  location  (e.g., 
Hilo  Hawaii  USA).  The  following  managed  object  classes  (or  any  of  their  subclasses  or  allomorphic 
classes)  are  valid  as  locations:    "0P1  Library  Vol.  4":Location. ! ; 

A.4.4.23  {Manufacturer  List 

manufacturerList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR    SUBSTRINGS,  SET -COMPARISON,  SET-INTERSECTION; 

BEHAVIOUR  manufacturerListBehaviour; 

REGISTERED  AS  Cx-attribute  23>; 

manufacturerListBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  manufacturerList  attribute  indicates  information  about  the  manufacturer(s)  that  manufactured 
the  underlying  resource.    This  attribute  contains  object  instance  name(s)  for  "0P1  Library  Vol. 
4": manufacturer  (or  any  subclass  or  allomorphic  class). 

Set  comparison  and/or  set  intersection  matching  rules  may  not  be  supported  by  some  managed  object 
instances  which  include  this  attribute. I; 

A.4.4.24  Manufacturer  Name 

manufacturerName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .AnyNameBase; 
MATCHES  FOR    EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  manufacturerNameBehaviour; 

REGISTERED  AS         Cx-attribute  24>; 
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manufacturerNaineBehaviour  BEHAVIOUR 
DEFINED  AS 

IThe  manufacturerName  attribute  indicates  information  about  the  manufacturer(s)  that  manufactured 
the  underlying  resource.    This  attribute  contains  descriptive  text. I; 

A.4.4.25  Max  Connections 

maxConnections  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDER I NG; 
BEHAVIOUR  maxConnectionsBehaviour; 

REGISTERED  AS        <x-attribute  25>; 

maxConnectionsBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  maxConnections  attribute  specifies  the  maximun  number  of  simultaneously  active/open  transport 
connections  that  can  be  supported  by  the  transport  protocol  layer  entity. !; 

A.4.4.26  Max  PDU  Size 

maxPDUSize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  maxPDUSizeBehaviour; 

REGISTERED  AS        {x-attribute  26>; 

maxPDUSizeBehaviour  BEHAVIOUR 

DEFINED  AS 

IThe  maxPDUSize  attribute  specifies  the  maximum  length  of  a  PDU  that  can  be  supported  by  the  local 
layer  entity. I ; 

A.4.4.27  Max  Retransmissions 

maxRetransmissions  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 . IntegerBase; 

HATCHES  FOR      EQUALITY,  ORDERING; 

BE  HAV I OUR    maxRet  r ansmi  ss  i  onsBehav  i  our ; 

REGISTERED  AS        Cx-attribute  27>; 

maxRetransmissionsBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  maximum  number  of  times  a  TPDU  is  to  be  retransmitted  before  the 
transport  connection  is  aborted.!; 

A.4.4.28  Memory  Size 

memorySize  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .MemorySizeBase; 
HATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR  memorySizeBehaviour; 
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REGISTERED  AS  {x-attribute  28>; 
meniorySizeBehaviour  BEHAVIOUR 
DEFINED  AS 

!The  Memory  Size  attribute  indicates,  in  kilobytes,  the  amount  of  memory  available  to  a  Processing 
Entity  (irrespective  of  its  current  usage). I; 

A.4.4.29  Memory  Utilization 

memoryUtilization  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 . IntegerBase; 

MATCHES  FOR  EQUALITY,  ORDERING; 
BEHAVIOUR    memoryUti I izationBehaviour; 

REGISTERED  AS  Cx-attribute  29>; 

memoryUti I izationBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  memoryUtilization  attribute  specifies,  as  a  percentage,  the  overall  utilization  of  amount  of 
memory  available  to  a  processing  entity.    The  percentage  is  expressed  as  an  integer  with  permissible 
values  in  the  range  of  0  to  100.1; 

A.4.4.30  Networl(  Entity  Type 

networkEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .NetworkEntityType; 

MATCHES  FOR  EQUALITY; 

BEHAVIOUR  networkEntityTypeBehaviour; 

REGISTERED  AS  <x-attribute  30>; 

networkEntityTypeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  networkEntityType  attribute  indicates  the  type  of  the  network  protocol  layer  entity.!; 

A.4.4.31  Network  Title 

networkTitle  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992" :systemTi tie; 
BEHAVIOUR  networkTitleBehaviour; 

REGISTERED  AS  tx-attribute  31>; 

networkTitleBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Network  Title  is  one  of  the  distinguishing  attribute  the  network  managed  object  class  for  use 
as  described  in  clause  6.3  of  [MIM]!; 

A.4.4.32  NPDU  Time  To  Live 

nPDUTimeToLive  ATTRIBUTE 
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WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR     EQUALITY,  ORDERING; 
BEHAVIOUR    nPDUT  i  meToL  i  veBehavi  our; 

REGISTERED  AS  {x-attribute  32>; 

nPDUTimeToLi veBehavi our  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  maximun  amount  of  time  (in  units  of  10  ms)  that  an  NPOU  can  exist  in 
the  network.    This  attribute  is  used  to  limit  the  lifetime  of  NPDUs  during  unstable  network 
situations. ! ; 

A.4.4.33  OMNIPoint  Equipment  Ust 

opEquipmentList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET-INTERSECTION; 
BEHAVIOUR  opEquipmentListBehaviour; 

REGISTERED  AS  (x-attribute  33>; 

opEquipmentListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  OMNIPoint  Equipment  List  attribute  provides  managed  object  instance  information  about  one  or 
more  pieces  of  opEquipment.    The  following  classes  (or  any  of  their  subclasses  or  allomorphic 
classes)  are  valid  as  equipment:  OMNIPoint  Equipment. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.34  OMNIPoint  Network  List 

opNetworkList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR    opNetwor kL  i  stBehavi  our; 

REGISTERED  AS  Cx-attribute  34>; 

opNetworkLi StBehavi our  BEHAVIOUR 

DEFINED  AS 

!The  OMNIPoint  Network  List  attribute  shall  provide  managed  object  instance  information  about  a  set 
of  networks.    The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are 
valid  as  networks:  OMNIPoint  Network. 

The  SET-COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.35  OMNIPoint  Network  Name 

opNetworkName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  opNetworkNameBehaviour; 
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REGISTERED  AS  Cx-attribute  35>; 
opNetworkNameBehaviour  BEHAVIOUR 
DEFINED  AS 

I  The  OMNIPoint  Network  Name  attribute  shall  provide  information  about  a  network. I; 

A.4.4.36  Operating  System  Information 

oslnfo  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1  .OsInfoBase.- 
MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECT  ION; 
BEHAVIOUR  osInfoBehaviour; 

REGISTERED  AS  {x-attribute  36>; 

osInfoBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Operating  System  Information  attribute  specifies  the  names  and  releases  of  the  supported 
operating  systems. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  nnay  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.37  PDUs  Forwarded  Counter 

pdusForwardedCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  j  ISO/IEC  10165-2  :  1992":  counter; 
BE  HAV I OUR       pdus  Forwa  rdedCount erBehav  i  our ; 

REGISTERED  AS        <x-attribute  37>; 

pdusForwardedCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  number  of  valid  incoming  PDUs  which  were  forwarded  (transmitted  as 
outgoing  PDUs)  to  another  destination.    This  attribute  does  not  count  incoming  PDUs  which  were 
delivered  to  a  local  service  user.!; 

A.4.4.38  PDUs  Reassembled  Ok  Counter 

pdusReasmbldOKCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR  pdusReasmbldOKCounterBehaviour; 

REGISTERED  AS        <x-attribute  38>; 

pdusReasmbldOKCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

!This  attribute  specifies  the  number  of  PDUs  that  were  reassembled  successfully  by  a  protocol  layer 
entity. ! ; 

A.4.4.39  PDUs  Reassembled  Fail  Counter 

pdusReasmbldFai iCounter  ATTRIBUTE 
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DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR    pdusReasmbldFai ICounterBehaviour; 

REGISTERED  AS        {x-attribute  39>; 

pdusReasmbldFai ICounterBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  number  of  valid  PDUs  received  by  a  protocol  layer  entity  but  discarded 
due  to  reassenibly  failure.    This  attribute  counts  only  incoming  PDUs  which  were  recognized  as  valid 
segments  of  an  SDU,  but  which  were  discarded  during  reassembly  (for  example,  due  to  reassembly  time 
expiration). I ; 

A.4.4.40  PDUs  Discarded  Counter 

pdusDiscardedCounter  ATTRIBUTE 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":  counter; 
BEHAVIOUR  pdusDiscardedCounterBehaviour; 

REGISTERED  AS        {x-attribute  40>; 

pdusDiscardedCounterBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  specifies  the  number  of  invalid  PDUs  received  and  discarded  by  a  protocol  layer 
entity. ! ; 

A.4.4.41  Peripheral  List 

peripheralList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BEHAVI OUR    per { phera I L  i  stBehavi  our; 

REGISTERED  AS  (x-attribute  41>; 

peri  phera I L  i  stBehavi  our  BEHAVI OUR 

DEFINED  AS 

!The  Peripheral  List  attribute  provides  managed  object  instance  information  for  peripheral  devices 
accessible  by  a  resource. 

The  Peripheral  List  attribute  identifies  the  auxiliary  devices  that  are  used  by  a  resource.  This 
includes  things  such  as  disk  drives,  tape  drives,  printers,  etc.. 

The  following  object  classes  (or  their  subclasses  or  allomorphic  classes)  are  valid  processing 
entities:  OMNI  Point  Equipment. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.42  Peripheral  Name 

peri phera I Name  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  peripheralNameBehaviour; 
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REGISTERED  AS  Cx-attribute  42>; 


per  i  phera I NameBehavi  our 


BEHAVIOUR 


DEFINED  AS 

!The  Peripheral  Name  attribute  provides  information  for  peripheral  devices  accessible  by  a  resource. 

The  Peripheral  Name  attribute  identifies  an  auxiliary  devices  that  is  used  by  a  resource.  This 
includes  things  such  as  disk  drives,  tape  drives,  printers,  etc..!; 

A.4.4.43  Processing  Entity  List 

process  i  ngEnt  i  tyL  i  st  ATTR I  BUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNamesBase; 

MATCHES  FOR  EQUALITY,  SET -COMPARISON,  SET- INTERSECTION; 

BE  HAV I OUR    process  i  ngEnt  i  tyL  i  s tBehavi  our; 

REGISTERED  AS  Cx-attribute  43>; 

process i ngEnt i tyL istBehavi our  BEHAVIOUR 

DEFINED  AS 

"The  Processing  Entity  List  attribute  specifies  the  processing  entities  which  may  be  used  by  the 
containing  object  instance  but  which  are  not  contained  in  (i.e.,  processing  entities  which  are 
shared  among  systems).    The  following  object  classes  (or  their  subclasses  or  allomorphic  classes) 
are  valid  processing  entities:  process i ngEnt ity. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 

A.4.4.44  Processing  Entity  Name 

process i ngEnt ityName  ATTRIBUTE 


DEFINED  AS 

!The  Processing  Entity  Name  attribute  specifies  the  processing  entity  which  may  be  used  by  the 
containing  object  instance  but  which  is  not  contained  in  (i.e.,  processing  entities  which  are  shared 
among  systems).!; 

A.4.4.45  Product  Label 

productLabel  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  productLabelBehaviour; 

REGISTERED  AS  Cx-attribute  A5>; 

productLabelBehaviour  BEHAVIOUR 


WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR    process i ngEnt ityNameBehavi our; 


REGISTERED  AS  {x-attribute  44>; 


process i ngEnt ityNameBehavi our 


BEHAVIOUR 


DEFINED  AS 
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IThe  productLabel  attribute  specifies  the  product  nuiter  or  identifying  string  (e.g.,  model  ntinber) 
of  the  underlying  resource. I; 

A.4.4.46  Remote  Network  Address 

remoteMetworkAddress  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .Address; 
MATCHES  FOR       EQUALITY.  SUBSTRINGS; 
BEHAVIOUR  remoteNetworkAddressBehaviour; 

REGISTERED  AS  Cx-attribute  46>; 

remoteNetworkAddressBehav  i  our     BE  HAV I OUR 

DEFINED  AS 

IThe  remoteNetworkAddress  attribute  identifies  the  remote  network  address  of  a  transport  connection 
(e.g.,  remote  IP  address  for  TCP  or  the  remote  NSAP  address  for  OSD.I; 

A.4.4.47  Remote  Transport  Connection  Endpoint 

remoteTransportConnect  i  onEndpoi  nt         ATTR I  BUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .Address; 

MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BEHAVIOUR     remoteTransportConnect ionEndpointBehaviour; 

REGISTERED  AS  <x-attribute  47>; 

remoteTransportConnect ionEndpointBehaviour  BEHAVIOUR 

DEFINED  AS 

IThis  attribute  identifies  the  remote  transport  connection  endpoint  (e.g.,  the  destination  port  for 
TCP  or  the  remote  t-selector  for  OSI  Transport  protocol).!; 

A.4.4.48  Retransmission  Time 

retransmissionTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .HundredthsOf Sec; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR    ret ransmi  ssi  onT  imeBehavi  our; 

REGISTERED  AS        <x-attribute  48>; 

ret  ransmi  ss  i  onT  i  meBehavi  our     BEHAVI OUR 

DEFINED  AS 

IThis  attribute  specifies  the  current  value  (in  1/100ths  of  a  second)  of  the  retransmission  timer 
used  by  a  transport  connection.!; 

A.4.4.49  Retransmission  Timer  initial  Value 

ret  ransmi  ss  i  onT  i  mer I ni  t  i  a I Va I ue   ATTR I BUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .HundredthsOf Sec; 

MATCHES  FOR      EQUALITY,  ORDERING; 

BEHAVIOUR  retransmissionTimerlnitialValueBehaviour; 

REGISTERED  AS        {x-attribute  49>; 
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retransmissionTimerlnitialValueBehaviour  BEHAVIOUR 
DEFINED  AS 

IThis  attribute  specifies  the  initial  value  (in  1/100ths  of  a  second)  of  the  retransmission  timer 
used  by  a  transport  connection.!; 

A.4.4.50  Serial  Number 

serialNumber  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  serialNumberBehaviour; 

REGISTERED  AS         {x-attribute  50>; 

serialNumberBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  serialNumber  attribute  provides  the  serial  number  of  the  underlying  resource.!; 

A.4.4.51  Service  List 

serviceList  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX  SYNTAX-1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  serviceListBehaviour; 

REGISTERED  AS  <x-attribute  51>; 

serviceListBehaviour  BEHAVIOUR 


!The  Service  List  attribute  provides  managed  object  instance  information  about  one  or  more  services. 
The  following  object  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid  as 
services:  "0P1  Library  Vol.  4":Service. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  ise  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 


DEFINED  AS 


A.4.4.52  Service  Name 


serviceName 


ATTRIBUTE 


WITH  ATTRIBUTE  SYNTAX    SYNTAX-1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVICXJR  serviceNameBehaviour; 


REGISTERED  AS  Cx-attribute  52>; 


servi  ceNameBehavi  our 


BEHAVIOUR 


DEFINED  AS 


!The  Service  Name  attribute  provides  information  about  one  service.!; 


A.4.4.53  Software  List 


softwareList 


ATTRIBUTE 
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WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECT  ION; 
BEHAVIOUR  softwareListBehaviour; 

REGISTERED  AS  Cx- at tribute  53>; 

softwareListBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Software  List  attribute  identifies  those  software  components  that  run  on  or  are  considered  part 
of  the  equipment.    (There  is  no  corresponding  managed  object  class  at  this  time.) 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute. I; 

A.4.4.54  Software  Name 

softwareName  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .AnyNameBase; 
MATCHES  FOR  EQUALITY,  SUBSTRINGS; 
BEHAVIOUR    sof twareNameBehaviour; 

REGISTERED  AS  <x-attribute  54>; 

sof twareNameBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  Software  Name  attribute  identifies  the  software  component  that  runs  on  or  are  considered  part 
of  the  equipment.!; 

A.4.4.55  System  Time 

systemTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .GeneralTime; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  systemTimeBehaviour; 

REGISTERED  AS        <x-attribute  55>; 

systemTimeBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  systemTime  attribute  specifies  the  current  time  clocked  at  the  resource.!; 

A.4.4.56  Transport  Connection  Id 

transportConnectionId  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX    SYNTAX- 1 .GraphicStringBase; 

MATCHES  FOR    EQUALITY,  SUBSTRINGS; 

BE  HAV I OUR    t  ranspor tConnec  t  i  onl dBehav  i  our ; 

REGISTERED  AS        tx-attribute  56>; 

transportConnectionldBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  transportConnectionId  attribute  is  the  distinguishing  attribute  for  the  transportConnection 
managed  object  class.!; 
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A.4.4.57  Transport  Connection  Reference 


transportConnectionReference 


ATTRIBUTE 


WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1.1 ntegerBase; 

MATCHES  FOR  EQUALITY; 

BE  HAV I OUR    t  ransportConnect  i  onRef erenceBehavi  our; 


REGISTERED  AS 


<x-attribute  57>; 


transportConnectionRef erenceBehavi our  BEHAVIOUR 
DEFINED  AS 

IThis  attribute  identifies  the  local  transport  connection  reference  that  is  established  by  the  two 
transport  connection  endpoints  (e.g.,  the  local  socket  nunber  for  TCP  or  the  local  connection 
reference  for  OSI).!; 

A.4.4.58  Transport  Entity  Type 

transportEntityType  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .TransportEntityType; 

MATCHES  FOR  EQUALITY; 

BEHAVIOUR  transportEntityTypeBehaviour; 

REGISTERED  AS         Cx-attribute  58>; 

t  ranspor t Ent  i  tyTypeBehav  i  our     BEHAV I OUR 

DEFINED  AS 

!The  transportEntityType  attribute  indicates  the  type  of  the  transport  protocol  layer  entity.!; 
A.4.4.59  Type  Text 

typeText  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 .GraphicStringBase; 
MATCHES  FOR      EQUALITY,  SUBSTRINGS; 
BEHAVIOUR  typeTextBehaviour; 

REGISTERED  AS         {x-attribute  59>; 

typeTextBehaviour  BEHAVIOUR 

DEFINED  AS 

!The  typeText  attribute  serves  to  supplement  and  refine  individual  managed  object  class  attributes. 
If  none  of  the  named  items  defined  for  the  "type"  attribute  are  appropriate,  or  the  "type"  attribute 
requires  refinement,  the  typeText  attribute  contains  supplemental  information.!; 

A.4.4.60  Up  Time 

upTime  ATTRIBUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX-1 . IntegerBase; 
MATCHES  FOR      EQUALITY,  ORDERING; 
BEHAVIOUR  upTimeBehaviour; 

REGISTERED  AS        Cx-attribute  60>; 

upTimeBehaviour  BEHAVIOUR 
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DEFINED  AS 


'The  upTime  attribute  specifies  the  time  interval  (in  seconds)  that  has  elapsed  since  the  entity's 
operational  state  changed  to  "enabled",  or  since  the  time  that  the  entity  was  created  in  the 
"enabled"  state.!; 


A.4.4.61  Vendor  List 


vendorList 


ATTRIBUTE 


WITH  ATTRIBUTE  SYNTAX  SYNTAX- 1 .AnyNamesBase; 
MATCHES  FOR  SET -COMPARISON,  SET- INTERSECTION; 
BEHAVIOUR  vendorListBehaviour; 


REGISTERED  AS  Cx- attribute  61 >; 


vendorL  i  stBehavi  our 


BEHAVIOUR 


DEFINED  AS 

!The  Vendor  List  attribute  provides  managed  object  instance  information  about  a  set  of  vendor 
organizations.  The  following  classes  (or  any  of  their  subclasses  or  allomorphic  classes)  are  valid 
as  vendors:    "0P1  Library  Vol.  4":Vendor. 

The  SET -COMPARISON  and/or  SET- INTERSECTION  matching  rules  may  not  be  supported  by  some  managed 
object  instances  which  include  this  attribute.!; 


A.4.5  Actions 


A.4.5.1  Activate 

--  Copied  from  ISO/IEC  DIS  10737,  should  be  replaced  by  reference  to  standard 
--  definition  when/if  this  ACTION  is  registered  in  a  final  IS  version. 

activate  ACTION 

BEHAVIOUR  activateBehaviour; 
MODE  CONFIRMED; 

WITH  REPLY  SYNTAX  SYNTAX-1 .ActivateActionReply; 
REGISTERED  AS  €  x-action  1  }; 


activateBehaviour  BEHAVIOUR 
DEFINED  AS 

!This  action  initializes  the  operation  of  the  resource.    As  a  result  of  the  action,  the  sequence  of 
operations  necessary  to  cause  the  resource  to  enter  its  operational  mode  shall  be  initiated.  These 
may  include,  for  example,  checks  against  attribute  constraint  violation  and  checks  on  the  validity 
of  relationship  attributes  (cross-layer  and  other).    If  these  operations  are  successfully  initiated, 
the  administrative  state  (if  present)  shall  be  changed  to  "unlocked"  and  the  value  "successResponse" 
shall  be  returned  in  the  responseCode  parameter  of  the  action  reply.    If  these  operations  cannot  be 
successfully  initiated,  the  value  "fai lureResponse"  shall  be  returned,  together  with  a  failure 
reason  parameter  describing  the  reason  for  the  failure.    On  successful  completion  of  these 
operations,  the  operational  state  shall  have  the  value  "enabled".    Depending  upon  the  current  state 
of  the  resource  when  the  action  is  attempted,  some  or  all  of  the  above  operations  may  be 
unnecessary. ! ; 
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A.4.5.2  Deactivate 

Copied  from  ISO/IEC  DIS  10737,  should  be  replaced  by  reference  to  standard 
definition  when/if  this  ACTION  is  registered  in  a  final  IS  version. 

deactivate  ACTION 

BEHAVIOUR  deactivateBehaviour; 
MODE  CONFIRMED; 

WITH  REPLY  SYNTAX  SYNTAX-1 .ActivateActionReply; 
REGISTERED  AS  i  x-action  2  >; 


deactivateBehaviour  BEHAVIOUR 
DEFINED  AS 

■This  action  terminates  the  operation  of  the  resource.    As  a  result  of  the  action,  the  sequence  of 
operations  necessary  to  cause  the  resource  to  cease  operation  shall  be  initiated.    If  these 
operations  are  successfully  initiated,  the  administrative  state  (if  present)  shall  be  changed  to 
"locked"  and  the  value  "successResponse"  shall  be  returned  in  the  responseCode  parameter  of  the 
action  reply.    If  these  operations  cannot  be  successfully  initiated,  the  value  "fai lureResponse" 
shall  be  returned,  together  with  a  failure  reason  parameter  describing  the  reason  for  the  failure. 
On  successful  completion  of  these  operations,  the  operational  state  shall  have  the  value  "disabled". 
Depending  upon  the  current  state  of  the  resource  when  the  action  is  attempted,  some  or  all  of  the 
above  operations  may  be  unnecessary. ! ; 


A.4.6  Parameters 


A.4.6.1  Transport  Disconnect  Cause 

t  ranspor to  i  sconnectCause  PARAMETER 

CONTEXT      EVENT- INFO; 

WITH  SYNTAX  SYNTAX-1 .Cause; 

BEHAVIOUR  causeBehaviour; 

REGISTERED  AS  i  x-parameter  1  >; 


causeBehaviour  BEHAVIOUR 
DEFINED  AS 

IThis  parameter  specifies  the  reason  why  a  transport  connection  was  deleted.  It  may  be  included  in 
the  Additional  Information  parameter  of  the  objectDeletion  notification.!; 


A.4.7  Syntax  Definitions 

SYNTAX-1  <  x-module  1  > 
DEFINITIONS  IMPLICIT  TAGS  ::=  BEGIN 

IMPORTS  DistinguishedName  FROM  InformationFramework  {joint- iso-ccitt  ds(5)  modules(l) 

informationFramework(1»  Object  Instance  FROM  CMIP-1  Cjoint-iso-ccitt  ms(9)  cmipd)  modulesCO)  protocol(3)>; 


EXPORTS  everything 


The  following  OIDs  are  allocated  from  the  OIW  NMSIG  registration  arc. 
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for  use  in  registering  harmonized  OIW/NMF  definitions. 


rwisig  OBJECT  IDENTIFIER 

opUibraryVoM  OBJECT  IDENTIFIER 

x-module  OBJECT  IDENTIFIER 

x-objectClass  OBJECT  IDENTIFIER 

x-package  OBJECT  IDENTIFIER 

x-nameBinding  OBJECT  IDENTIFIER 

x-attribute  OBJECT  IDENTIFIER 

x-attributeGroup  OBJECT  IDENTIFIER 

x-parameter  OBJECT  IDENTIFIER 

x-action  OBJECT  IDENTIFIER 

x-notification  OBJECT  IDENTIFIER 

x-responseCode  OBJECT  IDENTIFIER 


<  iso  identif ied-organization(3)  oiw(14)  ninsig(2}  > 

<  ninsig  2  > 

i  oplLibraryVoll  0  > 
i  oplLibraryVoll  1  > 
C  oplLibraryVoll  2  > 
i  oplLibraryVoll  3  > 
<.  oplLibraryVoll  4  > 
{  oplLibraryVoll  5  > 
i  oplLibraryVoll  6  > 
C  oplLibraryVoll  7  > 
i  oplLibraryVoll  8  > 
i  oplLibraryVoll  9  > 


By  convention,  the  postfix  "base"  is  used  when  defining  base  types  which  appear 

as  syntax  labels  in  ATTRIBUTE  templates  and  the  postfix  "range"  is  used  when  defining 

constrained  types  which  appear  as  syntax  labels  in  PERMITTED  VALUES  clauses. 


ActivateActionReply 


:=    SEQUENCE  { 

responseCode 
responseArgs 
> 


OBJECT  IDENTIFIER, 

SET  OF  Parameter  OPTIONAL 


--  OBJECT  IDENTIFIER  values  used  with  ActivateActionReply  -- 
fai lureResponse  OBJECT  IDENTIFIER  ::=  {  x- responseCode  1  > 
successResponse   OBJECT  IDENTIFIER  ::=    {  x- responseCode  2  > 


Address 


:=    OCTET  STRING 


Address  i  ngS  i  zeBase 


::=  CHOICE  i 

unknown  NULL, 

address ingSize  IntegerBase 


measured  in  bits 


Address  i  ngS  i  zeRange 


::=  CHOICE  < 

unknown  NULL, 

address ingSize      IntegerBase  (1..64) 


measured  in  bits 


AnyNamesBase 
AnyNameBase 


::=    SET  OF  Object  Instance 
Graph icStringBase 


AnyNamesRange 
AnyNameRange 


SET  SIZE(0..64)  OF  Object  Instance 
Graph icString64 


Cause 


:=    SEQUENCE  (. 


who  INTEGER  <: 

unknown 

user 

provider 
>. 

why  INTEGER  C 
unknown 
excess iveldle 


(0)  , 

(1)  . 
(2) 


<0), 
(1), 
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Endianess 


excess iveRetransmiss ions  (2) 
» 


ENUMERATED  < 

big  (1), 
little  (2) 
> 


Equ i pment I dRange 


CHOICE  { 

based  on  "Rec.  M.3100  :  1992"  ASN.1  Module  NameType 
numericName  Integer32, 
pString  GraphicString64 
> 


Genera  IT i me 


:=  GeneralizedTime 


G  raph  i  cSt  r  i  ngBase 
GraphicString16 
GraphicString32 
GraphicString64 


Graph icSt ring 

GraphicStringBase(SIZE(0..16}) 
GraphicStringBase(SIZE(0..32)) 
GraphicStringBase(SIZE(0..64)) 


HundredthsOfSec 


:=  IntegerBase 


IntegerBase 
Integer32 


:=  INTEGER 

:=    I ntegerBaseCO.. 4294967295) 


MemorySizeBase 


MemorySi  zeRange 


::=  CHOICE  i 
unknown  NULL, 

size  IntegerBase 
> 

CHOICE  < 

unknown  NULL, 

size  Integer32 

> 


measured  in  kilobytes 


measured  in  kilobytes 


NetworkEnt  i  tyType 


::=  INTEGER  <:  other  (0), 

oSI-clnp  (1), 

internet- IP  (2) 
>  (0..255) 


NetworkAddresses 
OsInfoBase 

OsInfoRange 


::=    SET  OF  Address 


SET  OF  SEQUENCE 

osName  GraphicStringBase, 
osRelease  GraphicStringBase 
> 

SET  OF  SEQUENCE 
i 

osName  GraphicString64, 
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osRelease  Graph icString64 
> 


Parameter 


SEQUENCE  C 

paramld       OBJECT  IDENTIFIER, 
paramlnfo   ANY  DEFINED  BY  paramld 
> 


PercentageRange 


:=    IntegerBase  (0..100) 


T  ranspor tAddresses 


:=   SET  OF  T ranspor tAddress 


Transport Address 


::=    SEQUENCE  C 

t  ranspor tConnect  i  onEndpo  i  nt  Address , 
networkAddress  Address 


T  ranspor tEnt  i  tyType 


::=  INTEGER  {  other  (0), 

oSI-TP  (1), 

tCP  (2), 

SNA  (3) 
>  (0..255) 


END 


A.4.8  Inheritance  &  Naming  Trees 

This  section  provides  graphic  depictions  for  the  inheritance  and  naming  trees  that  are  defined  in  the 
previous  sections. 

A.4.8. 1  Inheritance  Tree 


top  -+--  opEquipment   

+--  computerSystem 
+--  opNetMork 

+- -  coT ranspor tProtocol LayerEnt i  ty 
+- -  c INetworkProtocol LayerEnt i  ty 
+--  transportConnection 


process  i  ngEnt  i  ty 


A.4.8.2  Naming  Tree 


root  -+--  opNetwork  --+--  opNetwork 
I  i 

I  +--  computerSystem 
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+--  opEquipment 

I 

.  +--  DHI  system  -+--  coTransportProtocolLayerEntity  --  transportConn 

+--  clNetworkProtocolLayerEntity 
j 

+--  opEc|uipnient-+--  opEquipment 

+--  processingEntity 
! 

+--  CoTransportProtocolLayerEntity  --  transportConn 
+--  ClNetworkProtocolLayerEntity 

I 

+--  computerSystem  --+--  computerSystem 
+--  processingEntity 
+--  opEquipment 

+--  coTransportProtocolLayerEntity  --  transportConn 
+--  ClNetworkProtocolLayerEntity 


A.5  OIW  NMSIG  IVMO  Definitions 

The  definitions  specified  in  this  clause  can  be  referenced  by  using  the  label  "0P1  Library  Vol.  2"  (e.g., 
"0P1  Library  Vol.  2":transportConnectionlVMO). 

A.5.1  Managed  Object  Classes  and  Mandatory  Packages 

A.5. 1.1  Transport  Connection  IVMO 


transportConnectionlVMO     MANAGED  OBJECT  CLASS 

DERIVED  FROM  "Rec.  X.721  |  ISO/IEC  10165-2  :  1992":top; 
CHARACTERIZED  BY  transportConnectionlVMO-Package; 

REGISTERED  AS  <y-objectClass  1>; 


transportConnectionlVMO- Package  PACKAGE 

BEHAVI OUR    t  ranspor tConnect  i  onl VMO- behavi  our ; 
ATTRIBUTES 

transportConnectionlVMOId  GET, 

"0P1  Library  Vol.  1":inactivityTimeout    PERMITTED  VALUES  SYNTAX-1.Integer32  GET-REPLACE, 
"0P1  Library  Vol.  1":maxPDUSize    PERMITTED  VALUES  SYNTAX- 1.1 nteger32  GET-REPLACE; 
NOTIFICATIONS 

"Rec.  X.721  !  ISO/IEC  10165-2  :  1992":objectCreation, 
"Rec.  X.721  ISO/IEC  10165-2  :  1992":objectDeletion, 
"Rec.  X.721  I  ISO/IEC  10165-2  :  1992":attributeValueChange;; 


transportConnectionlVMO-behaviour  BEHAVIOUR 
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DEFINED  AS 

IThis  managed  object  class  is  an  IVMO  (Initial  Value  Managed  Object  class).    It  represents 
the  collection  of  characteristic  attributes  which  supply  default  and  initially  advertised 
attribute  values  to  be  used  by  instances  of  the  Transport  Connection  managed  object  class 
when  they  are  created.    There  can  be  only  one  instance  of  the  Transport  Connection  IVMO 
managed  object  class  for  each  instance  of  the  CO  Transport  Protocol  Layer  Entity  managed 
object  class.    Each  Transport  Connection  IVMO  instance  may  provide  initial  attribute  values 
for  newly-created  Transport  Connection  instances  with  the  same  superior. 

The  Attribute  List  parameter  of  the  ObjectCreation  notification  shall  contain  all  the 
attributes  of  the  created  transport  connection  IVMO  instance. 

The  Attribute  List  parameter  of  the  ObjectDeletion  notification  shall  contain  all  the 
attributes  of  the  deleted  transport  connection  IVMO  instance. 

Attributes  that  are  subject  to  the  AttributeValueChange  notification  are  :  "0P1  Library 
Vol.  1":inactivityTimeout,  "0P1  Library  Vol.  1":maxPDUSize.    All  attributeValueChange 
notifications  shall  include  the  Attribute  Identifier  List  parameter.!; 


A.5.1.2  Transport  Connection  Retransmission  IVMO 


transportConnectionRetransmissionlVMO     MANAGED  OBJECT  CLASS 

DERIVED  FROM  transportConnectionlVMO; 
CHARACTERIZED  BY  transportConnectionlVMO-Package; 

REGISTERED  AS    Cy-objectClass  2>; 


transportConnectionRetransmissionlVMO-Package  PACKAGE 
BEHAVIOUR  transportConnectionlVMO-behaviour; 
ATTRIBUTES 

"0P1  Library  Vol.  1":maxRetransmissions  PERMITTED  VALUES  SYNTAX-1 , Integer32  GET-REPLACE, 
"0P1  Library  Vol.  1":retransmissionTimerInitialValue 

PERMITTED  VALUES  SYNTAX-1 . Integer32  GET-REPLACE;; 


transportConnectionRetransmissionlVMO-behaviour  BEHAVIOUR 
DEFINED  AS 

IThis  managed  object  class  is  an  IVMO  (Initial  Value  Managed  Object  class).    It  represents 
the  collection  of  characteristic  attributes  which  supply  default  and  initially  advertised 
attribute  values  to  be  used  by  instances  of  the  Transport  Connection  managed  object  class 
that  support  retransmission,  when  they  are  created.    There  can  be  only  one  instance  of  the 
Transport  Connection  Retransmission  IVMO  managed  object  class  for  each  instance  of  the  CO 
Transport  Protocol  Layer  Entity  managed  object  class.    Each  Transport  Connection 
Retransmission  IVMO  instance  may  provide  initial  attribute  values  for  newly-created 
Transport  Connection  instances  with  the  same  superior. 

Attributes,  additional  to  those  inherited  from  the  transport  connection  IVMO  managed  object 
class,  that  are  subject  to  the  AttributeValueChange  notification  are  :  "0P1  Library  Vol. 
1":maxRetransmissions,  "0P1  Library  Vol.  1":retransmissionTimerInitialValue. ! ; 


A.5.2  Name  Bindings 
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A.5.2.1  Transport  Connection  IVMO  Name  Bindings 

transportConnectionlVMO-coTransportProtocolLayerEntity   NAME  BINDING 

SUBORDINATE  OBJECT  CLASS  transportConnectionlVMO  AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "0P1  Library  Vol,  1":coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionlVMOId; 
REGISTERED  AS    {y-nameBinding  1>; 

A.5.2.2  Transport  Connection  Retransmission  IVMO  Name  Bindings 

t ranspor tConnect  i onRet ransmi  ss i onl VMO- coTransportProtocol LayerEnt  i  ty  NAME  B I ND I NG 
SUBORDINATE  OBJECT  CLASS  transportConnectionRetransinissionlVMO 
AND  SUBCLASSES; 
NAMED  BY 

SUPERIOR  OBJECT  CLASS  "0P1  Library  Vol.  1":coTransportProtocolLayerEntity  AND  SUBCLASSES; 
WITH  ATTRIBUTE  transportConnectionlVMOId; 
REGISTERED  AS    <y-naiiieBinding  2>; 


A.5.3  Attributes 


A.5.3.1  Transport  Connection  IVMO  Id 


transport  Connect  i  on I VMO I d   AT  TR I  BUTE 

WITH  ATTRIBUTE  SYNTAX     SYNTAX- 1 .GraphicStringBase; 

MATCHES  FOR      EQUALITY,  SUBSTRINGS; 

BEHAVIOUR  transportConnectionlVMOIdBehaviour; 


REGISTERED  AS 


<y-attribute  1>; 


t  ranspor tConnect  i  on I VMO I dBeh  av  i  our     BE  H AV I OUR 

DEFINED  AS  IThis  attribute  is  the  distinguishing  attribute  for  the  managed  object  class 

transportConnectionlVMO. ! ; 

A.5.4  Syntax  Definitions 


SYNTAX-2  <  y-module  1  > 
DEFINITIONS  IMPLICIT  TAGS 


:=  BEGIN 


EXPORTS  everything 

The  following  OIDs  are  allocated  from  the  OIW  NMSIG  registration  arc, 
for  use  in  registering  OIW  NMSIG  MIL  definitions. 


nmsig 

op1LibraryVol2 
y-module 
y-objectClass 
y- package 
y-nameBinding 
y-attribute 


OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 


IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 


y-attributeGroup  OBJECT  IDENTIFIER 


=  { 

=  <: 

=  <: 

=  <: 

=  <: 

=  <: 

=  <: 

=  c 


iso  identif ied-organization(3)  oiw(14}  nnisig(2)  > 
nmsig  1  > 

> 
> 
> 

> 
> 


oplLibraryVol2  0 
op1LibraryVol2  1 
op1LibraryVol2  2 
op1LibraryVol2  3 
op1LibraryVol2  4 
oplLibraryVol2  5 
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yparameter  OBJECT  IDENTIFIER 
y-action  OBJECT  IDENTIFIER 

y- notification     OBJECT  IDENTIFIER 


=  C  oplLibraryVol2  6  > 
=  i  opILibraryVolZ  7  > 
=    {  opiLibraryVolZ  8  > 


END 


A.5.5  Inheritance  &  Naming  Trees 

This  section  provides  graphic  depictions  for  the  inheritance  and  naming  trees  that  are  defined  in  the 
previous  sections. 

A.5.5. 1  Inheritance  Tree 

top           transportConnectionlVMO    transportConnectionRetransmissionlVMO 

A.5.5.2  Naming  Tree 

coTransportProtocolLayerEntity  -+--  transportConnection 

I 

+--  transportConnectionlVMO 

+--  transport Connec t i onRet r ansmi ss i on I VMO 

A.6  OIW  NMSIG  Shared  Management  Knowledge  (SMK)  Definitions 

(Refer  to  the  Working  Implementation  Agreements  Document.) 
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Annex  B  (informative) 
NMSIG  Object  Identifiers 

(Refer  to  the  Working  Implementation  Agreements  Document  for  additional  information.) 
B.I  Introduction 

Tills  Annex  (B)  specifies  object  identifier  component  values  which  are  glot)aliy  unambiguous.  These  object 
identifiers  are  to  be  used  when  referencing  NMSIG-specified  infornnation  objects.  As  defined  in  Part  6  of 
these  agreements,  the  OIW  has  assigned  the  following  object  identifier  for  use  by  the  NMSIG: 

{  iso(1)  identified-organization(3)  oiw(14)  nmsig(2)  } 

The  following  object  identifiers  are  assigned  under  the  {  iso  identified-organization  oiw  nmsig  }  node, 
labelled  "nmsig". 


Table  B.I  -  Object  identifiers  assigned  under  "nmsig"  node 


Identifier 

Value 

Reference 

op1LibraryVol2 

1 

A. 5 

opILibraryVoll 

2 

A. 4 

By  inclusion  of  the  managed  object  (MO)  definitions  and  the  object  identifiers  in  Annex  A  and  Annex  B, 
respectively,  of  the  Stable  Implementors'  Agreements  (SIAs),  these  managed  object  (MO)  definitions  have 
become  formally  registered.  Implementors  of  part  18  of  the  SIAs  do  not  have  to  support  any  of  these  MOs. 
However,  even  though  Annex  A  and  Annex  B  are  informative  annexes,  any  implementation  that  claims  to 
conform  to  these  definitions  must  treat  these  definitions  as  normative  and  comply  with  the  relevant  portions 
of  Annex  A.4  and  A.5,  and  Annex  B. 


B.2  Harmonized  MIL  Object  Identifiers 

Harmonized  MIL  Object  Identifiers  are  assigned  under  the  "nmsig"  node  as  follows: 


nmsig  OBJECT  IDENTIFIER 

opILibraryVoll  OBJECT  IDENTIFIER 

x-module  OBJECT  IDENTIFIER 

x-objectClass  OBJECT  IDENTIFIER 

x-package  OBJECT  IDENTIFIER 

x-nameBinding  OBJECT  IDENTIFIER 

x-attribute  OBJECT  IDENTIFIER 

x-attributeGroup  OBJECT  IDENTIFIER 

x-parameter  OBJECT  IDENTIFIER 

x-action  OBJECT  IDENTIFIER 

x-notification  OBJECT  IDENTIFIER 

x-responseCode  OBJECT  IDENTIFIER 


iso  identif ied-organi2ation(3)  oiw(14)  nn)sig(2)  > 
nmsig  2  > 

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


opIL 
oplL 
opiL 
opiL 
opIL 
oplL 
op1L 
op1L 
op1L 
opiL 


braryVoll  0 
braryVoll  1 
braryVoll 
braryVoll 
braryVoll 
braryVoH 
braryVoll 
braryVoll 
braryVoll  8 
braryVoll  9 


B.2.1  Object  Class  Object  Identifiers 
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The  following  object  identifiers  are  assigned  under  the  {  x-objectClass  }  node: 

Table  B.2  -  Object  kJentifiers  assigned  under  "x-objectClass"  node 


Reference 

Identifier 

Value 

A.4.1.1 

conputerSystem 

1 

A.4.1.2 

coTranspor tProtoco I LayerEnt  i  ty 

2 

A.4.1.3 

clNetworkProtocolLayerEntity 

3 

A.4.1.A 

opEquipment 

4 

A. 4. 1.5 

opNetwork 

5 

A. 4. 1.6 

process  i  ngEnt  i  ty 

6 

A. 4. 1.7 

t  ranspor  t Connec  t  i  on 

7 

B.2.2  Package  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-package  }  node: 


Table  B.3  -  Object  identifiers  assigned  under  "x-package"  node 


Reference 

Identifier 

Value 

A. 4. 2.1 

address ingPkg 

1 

A.4.2.2 

checksumPDUsDiscardedPkg 

2 

A. 4. 2. 3 

contactListPkg 

3 

A. 4. 2. 4 

contactNamePkg 

4 

A.4.2.5 

cpuUt  i I i  zat  i  onPkg 

5 

A.4.2.6 

customerListPkg 

6 

A.4.2.7 

customerNamePkg 

7 

A. 4. 2.8 

functionListPkg 

8 

A. 4. 2. 9 

functionNamePkg 

9 

A. 4. 2. 10 

incomingProtocolErrorPkg 

10 

A. 4. 2. 11 

I ocat i onPoi nterPkg 

11 

A. 4. 2. 12 

manufacturer L  i  stPkg 

12 

A. 4. 2. 13 

manufacturerNatnePkg 

13 

A. 4. 2. 14 

maxPDUSizelVPkg 

14 

A. 4. 2. 15 

maxRet  ransmi  ss  i  onsPkg 

15 
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Reference 

Identifier 

Value 

A. A. 2. 16 

memorySizePkg 

16 

A. 4. 2. 17 

tnemoryUt  i  I  i  zat  i  onPkg 

17 

A. 4. 2, 18 

octetsRetransmittedPkg 

18 

A. A. 2. 19 

opNetworkListPkg 

19 

A. A. 2. 20 

opNetworkNamePkg 

20 

A. A. 2. 21 

opVersionPkg 

21 

A.A.2.22 

outgoingProtocolErrorPkg 

22 

A. A. 2. 23 

pdusRetransmittedCounterPkg 

23 

A.A.2.2A 

pdusRetransmi  ttedThresholdPkg 

2A 

A. A. 2. 25 

per  i  phera I L  i  stPkg 

25 

A. A. 2. 26 

per i phera I NamePkg 

26 

A. A. 2. 27 

process  i  ngEnt  i  tyL  i  stPkg 

27 

A. 4. 2. 28 

process ingEntityNamePkg 

28 

A. A. 2. 29 

product Labe I Pkg 

29 

A. A. 2. 30 

ret  r  ansmi  ss  i  onT  i  mePkg 

30 

A. A. 2. 31 

ret  r ansmi  ss  i  onT  i  mer I n i  t  i  a I Va I uePkg 

31 

A. A. 2. 32 

serialNumberPkg 

32 

A. A. 2. 33 

serviceLi StPkg 

33 

A.A.2.3A 

serviceNamePkg 

3A 

A. A. 2. 35 

softwareLi StPkg 

35 

A. A. 2. 36 

sof  twareNannePkg 

36 

A. A. 2. 37 

system! imePkg 

37 

A. A. 2. 38 

typeTextPkg 

38 

A. A. 2. 39 

upTimePkg 

39 

A. A. 2. AO 

usageStatePkg 

AO 

A.A.2.A1 

vendorLi StPkg 

A1 

B.2.3  Name  Bindings  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-nameBlnding  }  node: 
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Table  B.4  -  Object  Identifiers  assigned  under  "x-nameBinding"  node 


Reference 

Identifier 

value 

A. 4. 3. 2 

computerSystefli- system 

1 

A. 4. 3. 2 

computerSystem-opNetwork 

2 

A. 4. 3. 2 

coniput  er  Sys  t  em- comput  erSys  t  em 

3 

A. 4. 3. 3 

coTransportProtocolLayerEntity-computerSystem 

4 

A. 4. 3. 3 

coTransportProtocolLayerEntity-system 

5 

A. 4. 3. 3 

coTransportProtocol LayerEnt  i  ty-opEquipment 

6 

A. 4. 3. 4 

clNetworkProtocolLayerEntity-computerSystem 

7 

A. 4. 3. 4 

clNetworkProtocol LayerEnt ity-system 

8 

A. 4. 3. 4 

c I NetworkProtoco I LayerEnt  i  ty-opEqui  pment 

9 

A. 4. 3. 5 

opEqui pment -computerSystem 

10 

A. 4. 3. 5 

opEqui pment - system 

11 

A. 4. 3. 5 

opEqu  i  pment - equi  pment 

12 

A. 4. 3. 5 

opEqu  i  pment - opNetwor k 

13 

A. 4. 3. 6 

network-opNetwork- 1 

14 

A. 4. 3. 6 

network- opNetwork- 2 

15 

A. 4. 3. 6 

opNetwork-root 

16 

A. 4. 3. 8 

t  ranspor tConnec t  i  on-coT  ranspor tProtoco I LayerEnt  i  ty 

17 

B.2.4  Attribute  Object  Identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  x-attribute  }  node: 


Table  B.5  -  Object  identifiers  assigned  under  "x-attribute"  node 


Reference 

Identifier 

Value 

A. 4. 4.1 

act  i  veConnect  i  ons 

1 

A. 4. 4. 2 

address ingSize 

2 

A. 4. 4. 3 

checksumPDUsD  i  scardedCounter 

3 

A. 4. 4. 4 

computerSystemld 

4 

A. 4. 4. 5 

c I NetworkProtocol LayerEnt  i  ty I d 

5 

A. 4. 4. 6 

coTransportProtocol LayerEnt ityld 

6 

A. 4. 4. 7 

contactList 

7 
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Reference 

Identifier 

Value 

A. 4. 4. 8 

contactName 

8 

A. 4. 4. 9 

cpuType 

9 

A. 4. 4. 10 

cpuUt  i I i  zat  i  on 

10 

A. 4. 4. 11 

customerList 

11 

A. 4. 4. 12 

customerName 

12 

A. 4. 4. 13 

endianess 

13 

A. 4. 4. 14 

functionList 

14 

A. 4. 4. 15 

functionName 

15 

A. 4. 4. 16 

inactivityTitne 

16 

A. 4. 4. 17 

i  nact  i  vi  tyT  i  meout 

17 

A. 4. 4. 18 

localNetworkAddress 

18 

A. 4. 4. 19 

localNetworkAddresses 

19 

A. 4. 4. 20 

localTransportAcidresses 

20 

A. 4. 4. 21 

localTransportConnectionEndpoint 

21 

A. 4. 4. 22 

locationPointer 

22 

A. 4. 4. 23 

tnanuf  acturerL  i  st 

23 

A. 4. 4. 24 

manufacturerName 

24 

A. 4. 4. 25 

maxConnections 

25 

A. 4. 4. 26 

maxPDUSize 

26 

A. 4. 4. 27 

maxRet  ransmi  ss  i  ons 

27 

A. 4. 4. 28 

memoryS  i  ze 

28 

A. 4. 4. 29 

memoryUt  i I i  zat  i  on 

29 

A. 4. 4. 30 

networkEnt  i  tyType 

30 

A. 4. 4. 31 

network! i tie 

31 

A. 4. 4. 32 

npduTimeToLive 

32 

A. 4. 4. 33 

opEquipmentList 

33 

A. 4, 4. 34 

opNetworkList 

34 

A. 4. 4. 35 

opNetworkName 

35 

A. 4. 4. 36 

OS Info 

36 

A. 4. 4. 37 

pdusForwardedCounter 

37 

A. 4. 4. 38 

pdusReasflfibldOkCounter 

38 

A. 4. 4. 39 

pdusReasmbldFai ICounter 

39 
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Reference 

Identifier 

Value 

A. 4. 4. 40 

pdusD  i  scardedCounter 

A. 4. 4. 41 

peripheral  Li  St 

H  1 

A. 4. 4. 42 

per i phera I Name 

L7 

HC 

A. 4. 4. 43 

process  i  ngEnt  i  tyL  i  st 

A-.4.4.44 

process ingEnti  tyName 

44 

A. 4. 4. 45 

productLabel 

45 

A. 4. 4. 46 

remoteNetworkAddress 

46 

A. 4. 4. 47 

retnoteTransportConnect  i  onEndpoi  nt 

47 

A. 4. 4. 48 

ret  ransmi  ss  i  onT  i  me 

48 

A. 4. 4. 49 

ret  r ansmi  ss  i  onT  i  mer Initial Va I ue 

49 

A. 4. 4. 50 

serialNumber 

50 

A. 4. 4. 51 

serviceList 

51 

A. 4. 4. 52 

serviceName 

52 

A. 4. 4. 53 

sof twareList 

53 

A. 4. 4. 54 

sof twareName 

54 

A. 4. 4. 55 

system!  ifne 

55 

A. 4. 4. 56 

t  ranspor tConnec  t  i  onl d 

56 

A. 4. 4. 57 

transportConnectionReference 

57 

A. 4. 4. 58 

t  ranspor tEnt  i  tyType 

58 

A. 4. 4. 59 

typeText 

59 

A. 4. 4. 60 

upTime 

60 

A. 4. 4. 61 

vendorList 

61 

B.2.5  Action  Object  Identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  x-action  }  node: 

Table  B.6  -  Object  identifiers  assigned  under  "x-action"  node 


Reference 

Identifier 

Value 

A. 4. 5.1 

activate 

1 

A, 4. 5. 2 

deactivate 

2 
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B.2.6  Parameter  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-parameter  }  node: 

Table  B.7  -  Object  identifiers  assigned  under  "x-parameter"  node 


Reference 

Identifier 

Value 

A. 4. 6.1 

t  ransportD  i  sconnectCause 

1 

B.2.7  Response  Code  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-responseCode  }  node: 

Table  8.8  -  Object  identifiers  assigned  under  "x-responseCode"  node 


Reference 

Identifier 

Value 

A. 4. 7 

fai lureResponse 

1 

A. 4. 7 

successResponse 

2 

8.2.8  Module  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  x-module  }  node: 

Table  8.9  -  Object  identifiers  assigned  under  "x-module"  node 


Reference 

Identifier 

Value 

A. 4. 7 

SYNTAX- 1 

1 

8.3  Phase  1  MIL  Object  Identifiers 

Phase  1  MIL  Object  Identifiers  are  assigned  under  the  "nmsig"  node  as  follows: 


op1LibraryVol2  OBJECT  IDENTIFIER 

y-module  OBJECT  IDENTIFIER 

y-objectClass  OBJECT  IDENTIFIER 

y-package  OBJECT  IDENTIFIER 

y-nameBinding  OBJECT  IDENTIFIER 

y-attribute  OBJECT  IDENTIFIER 

y-attributeGroup  OBJECT  IDENTIFIER 

y-parameter  OBJECT  IDENTIFIER 

y- act  ion  OBJECT  IDENTIFIER 

y-notification  OBJECT  IDENTIFIER 


nmsig  1  > 


opiL 
opIL 
opIL 
opiL 
opIL 
opIL 
opIL 
oplL 
opIL 


braryVol2  0 
braryVol2  1 
braryVol2 
braryVol2 
braryVol2 
braryVol2 
braryVol2 
braryVol2 
braryVol2  8 


8.3.1  Object  Class  Object  Identifiers 
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The  following  object  identifiers  are  assigned  under  the  C  y-objectClass  >  node: 


Table  B.IO  -  Object  identifiers  assigned  under  "y-objectClass"  node 


Reference 

Identifier 

Value 

A. 5. 1.1 

transport  Connec  t  i  on I VMO 

1 

A. 5. 1.2 

transport Connect  i  onRet  ransmi  ssi  onl VMO 

2 

B.3.2  Name  Bindings  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-nameBinding  }  node: 

Table  B.11  -  Object  identifiers  assigned  under  "y-na'^®B>ndin9"  nod® 


Reference 

Identifier 

Value 

A. 5. 2.1 

transportConnectionlVMO-coTransportProtocolLayerEntity 

1 

A. 5. 2. 2 

transportConnectionRet ransmi ssi onl VMO- 
coTransportProtocolLayerEntity 

2 

B.3.3  Attribute  Object  Identifiers 

The  following  object  Identifiers  are  assigned  under  the  {  y-attribute  }  node: 

Table  B.12  -  Object  identifiers  assigned  under  "y-attribute"  node 


Reference 

Identifier 

Value 

A. 5. 3.1 

t  r anspor tConnec  t  i  on I VMO I d 

1 

B.3.4  Module  Object  Identifiers 

The  following  object  identifiers  are  assigned  under  the  {  y-module  }  node: 

Table  B.13  -  Object  identifiers  assigned  under  "y-module"  node 


Reference 

Identifier 

Value 

A. 5. 4 

SYNTAX-2 

1 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Remote  Database  Access  (RDA) 
Special  Interest  Group  (RDASIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW).  See 
Procedures  Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  20  -  Manufacturing  Message  Specification  (MMS) 


0  Introduction 

This  section  defines  Implementors  Agreements  based  on  Manufacturing  Message  Specification  (MMS),  as 
defined  in  ISO/IEC  9506.  ISO/IEC  9506  hias  two  parts.  Part  1  defines  the  Virtual  Manufacturing  Device 
(VMD),  its  subordinate  abstract  objects,  and  the  sen/ices  on  these  objects.  Part  2  defines  the  protocol. 
Future  parts  may  define  companion  standards. 

MMS,  as  described  in  ISO/IEC  9506,  is  based  on  the  following  ISO  documents:  ACSE  Sen/ice  and  Protocol 
(ISO  8649,  ISO  8650),  Presentation  Service  and  Protocol  (ISO  8822,  ISO  8823),  ASN.1  Abstract  Syntax 
Notation  and  Basic  Encoding  Rules  (ISO  8824,  ISO  8825).  and  Session  Service  and  Protocol  (ISO  8326,  ISO 
8327).  These  sen/ices  and  protocols  are  defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498). 
These  agreements  provide  detailed  guidance  for  the  implementor,  and  eliminate  ambiguities  in 
interpretations. 

An  A-Profile  based  on  MMS  and  these  agreements  can  be  used  over  any  T-Profile  (see  ISO  TR  10000) 
specifying  the  OSI  connection-mode  transport  service,  or  the  transport  profiles  used  in  support  of  MAP 
(Manufacturing  Automation  Protocol),  TOP  (Technical  and  Office  Protocols),  or  US  GOSIP. 


1  Scope 


2     Field  of  Application 


2.1  General 

Work  on  implementation  agreements  will  proceed  in  phases  based  upon  grouping  of  sen/ices  and/or 
contexts.  Implementations  are  not  constrained  from  implementing  sen/ices  or  contexts  not  addressed  by 
the  current  set  of  stable  agreements.  Future  phases  of  work  may  affect  such  implementations. 


2.2      Phase  1  agreements 

These  agreements  will  be  based  on  a  subset  of  MMS  services  and  protocol  listed  in  table  1  and  defined  in 
ISO/IEC  9506-1  and  ISO/IEC  9506-2. 
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Table  1  -  Phase  1  Services 


Initiate 
Conclude 
Reject 
Abort 

Status 

GetNameList 

Identify 

UnsolicitedStatus 
GetCapabi 1 i  tyLi  st 

Ini  t  i  at eDownloadSequence 

DownloadSegment 

TerminateDownloadSequence 

InitiateUploadSequence 

UploadSegment 

TerminateUploadSequence 

DeleteDomain 

GetDomainAt tributes 

Read 
Write 

Inf ormat  ionRepor t 
GetVariableAccessAt tributes 

Input 
Output 

CreateProgramlnvocation 

DeleteProgramlnvocation 

Start 

Stop 

Resume 

Reset 

Kill 

Get ProgramlnvocationAt tributes 


3     Normative  References 

[1]       ISO/IEC  9506-1 :  1 990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part 
1:  Sen/ice  definition 

[2]       ISO/IEC  9506-2:  1 990  -  Industrial  automation  systems  -  Manufacturing  Message  Specification  Part 
2:  Protocol  specification 
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The  definitions  given  in  ISO/IEC  9506-1  are  applicable  to  this  document. 
In  addition  the  following  definitions  are  used  in  this  document: 

MMS  Implementation  a  term  used  to  describe  a  system  which  conforms  to  ISO/IEC  9506,  acting 

either  as  client  or  server,  when  it  is  unnecessary  to  distinguish  between  the  MMS-user 
and  the  h/lMS-provider. 

MMSpdu  Any  valid  value  of  the  MMSpdu  abstract  data  type  as  defined  in  Clause  7  of  ISO/IEC 

9506-2,  except  for  the  initiate-RequestPDU,  initiate-ResponsePDU,  and  initiate-ErrorPDU 
choices,  encoded  in  the  negotiated  transfer  syntax. 

5    Corrigenda  and  addenda 

(Refer  to  Working  Agreements.) 


6  Status 

(Refer  to  Working  Agreements.) 


7     General  agreements 


7.1      Max  supported  PDU  size 

The  max_mms_pdu_size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  shall  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  initiate-Error  PDU.  The  max_mms_pdu_size  shall  be  negotiated  during 
connection  initiation  using  the  Local  Detail  Calling  and  Local  Detail  Called  parameters  of  the  MMS  initiate 
service. 

The  negotiated  max_mms_pdu_size  shall  be  applied  as  follows: 

a)  Any  received  MMSpdu  whose  length  is  less  than  or  equal  to  the  negotiated  max_mms_pdu_size 
shall  be  properly  parsed  and  processed. 

b)  An  MMS  implementation  should  not  send  an  MMSpdu  whose  size  exceeds  the  negotiated 
max_mms_pdu_size.  If  an  MMS  implementation  sends  an  MMSpdu  that  exceeds  the  negotiated 
max_mms_pdu_size,  then  it  shall  be  prepared  to  receive  a  reject  pdu.  Should  an  MMS 
implementation  receive  an  MMSpdu  that  exceeds  the  negotiated  max_mms_pdu_size,  it  shall  either 
reject  the  MMSpdu  or  accept  the  MMSpdu  as  if  no  size  violation  had  occurred  and  perform  the 
expected  processing. 
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c)  If  an  MMS  implementation  is  unable  to  send  a  service  response  because  tlie  response  would 
exceed  the  max_mms_pdu_size,  then  it  shall  return  a  Service  response  (-)  with  an  error  class  of 
SERVICE  and  an  error  code  of  OTHER. 

d)  When  rejecting  an  MMSpdu  because  it  exceeds  the  negotiated  max_mms_pdu_size,  an  MMS 
implementation  shall  use  a  Reject  PDU  Type  of  PDU-ERROR  and  a  Reject  Code  of  INVALID-PDU 
in  the  resulting  reject  pdu. 

7.2  FileName 

Restrictions  for  the  use  of  the  type  FileName  in  the  MMS  Abstract  Syntax  are  specified  in  section  9.1  of  part  I 
9  of  these  agreements. 

8     Service-specific  agreements 
8.1      Environment  and  general  management 

8.1.1  Initiate 

8.1.1.1         Negotiation  of  MMS  abstract  syntaxes 

On  the  A-ASSOCIATE  response,  the  MMS  responder  shall  not  accept  more  than  one  presentation  context 
derived  from  an  MMS  abstract  syntax.  For  this  agreement,  the  term  'MMS  abstract  syntax'  shall  represent 
an  abstract  syntax  from  the  set  containing  the  abstract  syntax  defined  in  clause  19  of  ISO/IEC  9506-2  and 
abstract  syntaxes  defined  by  MMS  companion  standards. 


NOTE  -  There  are  technical  problems  with  describing  operation  in  multiple  MMS  abstract  syntaxes  over  a 
single  association.  These  problems  have  been  identified  as  of  9/90,  and  form  the  basis  of  the  prior  agreement. 

8.1.1.2        Max  serv  outstanding 

An  MMS  Implementation  which  intends  to  conform  only  with  the  Client  Conformance  Requirements  for 
Requester  CBBs  shall: 

a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called  parameter 
in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling  parameter  in 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 

An  MMS  Implementation  which  intends  to  conform  to  one  or  more  Server  Conformance  Requirements  for 
Responder  CBBs  shall: 
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a)  propose  one  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  paranneter 
in  the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  one  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called  parameter  in 
the  Initiate  service  when  receiving  the  application  association  initiation  (called). 


The  local  detail  calling  parameter  in  the  initiate  request  primitive  shall  specify  the  max_mms_pdu_size 
guaranteed  to  be  supported  by  the  calling  MMS  implementation.  If  the  local  detail  calling  parameter  is 
absent  from  the  request  primitive,  then  the  calling  MMS  implementation  guarantees  support  for  an  unlimited 
max_mms_pdu_size. 

If  present  In  the  request  or  indication  primitives,  the  local  detail  calling  parameter  shall  not  be  less  than  64; 
however,  it  is  recommended  that  at  least  512  octets  be  supported. 


8.1.1.4        Local  detail  called 

The  local  detail  called  parameter  in  the  initiate  response  shall  specify  the  negotiated  max_mms_pdu_size 
for  the  application  association. 

If  the  local  detail  calling  parameter  was  omitted  in  the  indication  primitive,  then  the  local  detail  called 
parameter: 

a)  may  be  omitted  from  the  response,  indicating  that  the  calling  MMS  implementation  and  the 
called  MMS  implementation  are  prepared  to  support  an  unbounded  max_mms_pdu_si2e; 

b)  may  be  specified  in  the  response,  indicating  a  requirement  to  support  the  specified  value  for 
max_mms_pdu_size. 

If  the  local  detail  calling  parameter  was  included  in  the  request,  then  this  parameter  shall  be  present  in  the 
response  and  its  value  shall  be  less  than  or  equal  to  the  value  of  the  local  detail  calling  parameter  of  the 
request. 

If  present  in  the  response,  the  local  detail  called  parameter  shall  not  be  less  than  64;  however,  it  is 
recommended  that  at  least  512  octets  be  supported. 


8.1.1.3 


Local  detail  calling 


8.2 


VMD  support 
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8.3 


Domain  management 


8.3.1 


List  of  capabilities 


Only  one  capability  shall  be  described  in  each  Visible  String  of  the  SEQUENCE  OF. 


8.3.2 


Initiate  Download  Sequence  service 


The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

The  syntax  and  semantics  of  the  capabilities  shall  be  defined  by  the  Server  in  the  PICS.  Any  deviation  from 
the  defined  syntax  and  semantics  shall  be  grounds  for  the  Server  to  return  a  service  error  with  Error  Class 
=  RESOURCE  and  Error  Code  =  CAPABILITY-UNKNOWN. 


A  client  that  receives  a  Download  Segment  indication  after  issuing  a  Download  Segment  Resuit(+)  with  the 
MoreFollows  parameter  equal  to  FALSE  or  after  issuing  a  Download  Segment  Result(-)  shall  issue  either  a 
service  error,  specifying  an  Error  Class  =  SERVICE  and  an  Error  Code  =  PRIMITIVES-OUT-OF-SEQUENCE, 
or  an  Abort  request. 


If  a  client  receives  a  Terminate  Download  Sequence  indication  in  which  the  Discard  parameter  is  absent  and 
the  client  has  not  issued  a  Download  Segment  response  with  the  More  Follows  parameter  =  FALSE  for  that 
Domain,  it  shall  behave  as  if  it  had  received  a  Terminate  Download  Sequence  indication  with  the  Discard 
parameter  present  with  error  class  =  VMD-STATE  and  error  code  =  DOMAIN-TRANSFER-PROBLEM.  It  is 
then  up  to  the  client  application  to  determine  the  true  state  of  the  Domain  and  take  any  recovery  action. 


8.3.5       Initiate  Upload  Sequence  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 


8.3.6       Upload  Segment  service 

A  server  that  receives  an  Upload  Segment  indication  for  an  Upload  State  Machine  for  which  it  has  issued 
an  Upload  Segment  Result(-)  or  an  Upload  Segment  Resuit(+)  with  the  MoreFollows  parameter  equal  to 
FALSE,  shall  issue  either  a  service  error,  specifying  an  Error  Class  =  SERVICE  and  an  Error  Code  = 
PRIMITiVES-OUT-OF-SEQUENCE,  or  an  Abort  request. 


8.3.3 


Download  Segment  service 


8.3.4 


Terminate  Download  Sequence  service 
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8.3.7  Get  Domain  Attributes  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

8.3.8  Get  Capability  List  service 

The  List  of  Capability  parameter  shall  follow  the  limitations  of  8.3.1. 

8.4      Program  Invocation  management 

8.4.1  Start  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Start  a  non- 
existent Program  Invocation  is  received. 

8.4.2  Stop  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Stop  a  non- 
existent Program  Invocation  is  received. 

8.4.3  Resume  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Resume  a  non- 
existent Program  Invocation  is  received. 

8.4.4  Reset  service 

A  ProgramlnvocationState  of  non-existent  shall  be  returned  in  a  Result(-)  when  a  request  to  Reset  a  non- 
existent Program  Invocation  is  received. 


It  is  strongly  recommended  that  for  services  which  use  variable  access,  a  Variable  List  Name  or  List  of 
Variable  be  used  instead  of  Scattered  Access. 

No  implementations  shall  be  required  to  propose  or  accept  the  VSCA  Parameter  CBB. 


8.5 


Variable  access 


8.5.1 


Scattered  access 
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8.5.2       Floating  point 

It  is  strongly  recommended  for  sen/Ices  which  use  floating  point  types  or  values,  that  the  choice  of  floating- 
point in  the  Data  and  TypeSpecification  productions  be  used  instead  of  the  real  choice. 

No  implementations  shall  be  required  to  propose  or  accept  the  REAL  parameter  CBB. 

8.6  Semaphore  management 

Semaphore  sen/ices  are  not  considered  in  Phase  1 . 

8.7  Operator  communication 

No  Operator  Communication  agreements  have  been  identified  to  date. 

8.8  Event  management 

Event  Management  services  are  not  considered  in  Phase  1 . 

8.9  Journal  management 

Journal  Management  services  are  not  considered  in  Phase  1. 
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Annex  A  (normative) 

Backwards  compatibility  agreements 


A.1  Introduction 

There  is  an  installed  base  of  real  DIS  9506  based  Implementations.  Providing  support  for  application 
connectivity  to  both  DIS  and  IS  is  desired  as  a  migration  strategy.  These  implementation  agreements  will 
allow  IS  based  implementations  to  interoperate  with  DIS  based  implementations  as  described  in  ANNEX  B. 
To  achieve  this  backwards  compatibility,  the  IS  implementation  shall  support  all  of  the  agreements  in  this 
section. 

It  was  found  that  the  Abstract  Syntax  name  object  identifiers  of  both  DIS  and  IS  were  identical.  Therefore, 
the  use  of  zero  as  the  version  number  allows  differentiation  between  an  IS  and  a  DIS  based  implementation. 
Since  the  abstract  syntax  name  object  identifier  of  any  companion  standard  is  different  from  that  used  by 
the  DIS  implenrientations,  DIS  implementations  cannot  interoperate  with  IS  based  implementations  in  a 
companion  standard  context. 

NOTES 

1  The  value  of  zero  is  a  valid  value  for  this  parameter  in  the  DIS  and  not  in  the  IS. 

2  There  are  three  types  of  implementations  when  considering  MMS  backwards  compatibility. 

IMP-1 :  An  implementation  based  on  DIS  9506  as  described  in  Annex  B; 

IMP-2:  An  implementation  based  on  IS  9506  with  no  backwards  compatibility  agreements 

applied; 

IMP-3:  An  implementation  based  on  IS  9506  which  includes  the  backwards  compatibility 

agreements  of  this  annex.  Such  an  implementation  can  dynamically  negotiate  to 
interoperate  with  an  IMP-1,  an  IMP-2,  or  an  IMP-3  implementation. 

Since  the  value  of  the  minor  version  number  is  zero  for  DIS-based  implementations,  and  is  one  or  greater 
for  implementations  of  ISO/IEC  9506,  this  value  can  be  used  to  differentiate  between  IMP-1  and  IMP-2.  An 
IMP-3  system  can  interoperate  with  either  of  these  systems.  If  an  IMP-3  is  the  Calling  system,  it  will  offer  a 
value  of  one  (or  greater)  for  the  proposed  version  number.  An  IMP-1  system  will  respond  with  a  value  of  the 
negotiated  version  number  of  zero,  using  the  negotiation  procedure  defined  in  ISO/IEC  9506.  The  IMP-3 
system  will  accept  this  response.  If  the  IMP-3  system  is  the  Called  system  and  has  received  an  Initiate 
request  with  a  value  of  zero  for  the  proposed  version  number  (from  an  IMP-1  system),  it  will  respond  with 
a  value  of  zero  for  the  negotiated  version  number.  By  following  this  procedure,  an  IMP-3  can  interoperate 
with  an  IMP-2  or  with  another  IMP-3  viewed  as  an  IMP-2.  After  association  context  establishment,  an  IMP-3 
system  shall  behave  as  either  an  IMP-1  or  an  IMP-2  system  as  appropriate  on  that  particular  association. 
The  remainder  of  this  section  describes  additional  agreements  which  change  an  IMP-2  implementation  into 
an  IMP-3  implementation. 
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A.2      Backwards    compatibility    agreements    for    calling  MMS 
implementations 

A  calling  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  negotiatedVersionN umber 
parameter  in  the  Initiate  Service  confirm  of  zero. 

A  calling  MMS  implementation  which  has  received  a  negotiatedVersionNumber  parameter  in  the  Initiate 
Service  confirm  of  zero  shall  support  the  modifications  described  in  A.4. 

A  calling  MMS  implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter  value 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  confirm. 

A  calling  MMS  implementation  which  has  received  a  negotiatedVersionNumber  of  zero  shall  be  capable  of 
receiving  and  supporting  an  Initiate  Response  which  has  been  encoded  according  to  the  modifications 
described  in  Appendix  B,  specifically  the  capability  of  receiving  and  supporting  a  negotiated ParameterCBB 
containing  exactly  7  bits. 

If  a  calling  MMS  implementation  receives  an  Initiate  confirm  primitive  with  a  negotiatedVersionNumber 
parameter  equal  to  zero,  the  calling  MMS  implementation  shall  support  the  VLIS  conformance  building  block 
if  the  implementation  claims  support  for  any  sen/ice  which  contains  one  or  more  parameters  which  indicate 
the  VLIS  CBB  in  its  service  definition. 

A.3      Backwards    compatibility    agreements    for    called  MMS 
implementations 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  a  proposedVersionNumber 
parameter  in  the  Initiate  Service  indication  of  zero. 

A  called  MMS  implementation  which  has  received  a  proposedVersionNumber  parameter  in  the  Initiate 
Service  indication  of  zero  shall  support  the  modifications  in  A.4. 

A  called  MMS  implementation  shall  be  capable  of  receiving  an  Application  Context  Name  parameter 
appropriate  to  an  IMP-1  or  IMP-2  in  the  A-Associate  indication. 

A  called  MMS  implementation  shall  be  capable  of  receiving  and  supporting  an  Initiate  Request  which  has 
been  encoded  according  to  the  modifications  described  in  Appendix  B,  specifically  the  capability  of  receiving 
and  supporting  a  proposedParameterCBB  containing  exactly  7  bits. 

If  a  called  MMS  implementation  receives  an  Initiate  indication  primitive  with  a  proposedVersionNumber 
parameter  equal  to  zero,  the  called  MMS  implementation  shall  support  the  VLIS  conformance  building  block 
if  the  implementation  claims  support  for  any  service  which  contains  one  or  more  parameters  which  indicate 
the  VLIS  CBB  in  its  service  definition. 
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A.4      General  backwards  compatibility  agreements 


A.4.1       VMD  logical  status 


If  the  current  VMD  State  is  SUPPORT-SERVICES-ALLOWED  and  the  association  nninor  version  number  Is 
zero,  then  the  vmdLogicalStatus  parameter  shall  have  a  value  of  STATE-CHANGES-ALLOWED  in  a  Status 
response  or  in  an  unsolicitedStatus  request. 


11 


PART  20  -  MMS  December  1991  (Stable) 

Annex  B  (normative) 

DIS  9506  Modifications  Required  for  Backwards  Compatibility 
B.1  Introduction 

This  annex  is  an  integral  part  of  this  part.  It  documents  the  modifications  to  DIS  9506  required  to  describe 
implementations  for  which  the  agreements  of  this  part  provide  backwards  compatibility.  This  annex  as 
applied  to  DIS  9506  is  referred  to  as  Version  0. 


B.2  References 

[1]       MMS/1  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Sen/ice  Definition,  December  1987 

[2]       MMS/2  Manufacturing  Message  Specification  -  ISO  DIS  9506  -  Protocol  Specification,  December 
1987 

[3]       NBS  OSI  Implementors  Workshop  Agreements  -  December  1 987 

B.3  General 

B.3.1       Implementation  base 

Version  0  is  based  upon  Reference  [3]  in  B.2  as  it  applies  to  MMS. 
B.3.2       Rules  of  extensibility 

The  following  sentence  is  appended  to  the  last  paragraph  in  section  8.2.1.1.5.2  Proposed  Parameter  CBB 
and  the  last  paragraph  in  section  8.2.1.2.5.2  Negotiated  Parameter  CBB  of  DIS  9506-1. 

"Any  additional  bits  shall  be  ignored." 

B.4      Modifications  to  the  protocol  definitions 
B.4.1       Page  39,  Section  7.5.2  of  DIS  9506-2 
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CHANGE 

reportEventEnrollmentStatus 

[60] 

IMPLICIT 

ReportEventEnrollmentStatus 

-Request , 

TO 

reportEventEnrollmentStatus 

[60] 

ReportEventEnrollmentStatus 

-Request , 

B.4.2       Page  49,  Section  7.6.4,  DIS  9506-2 


CHANGE 

ApplicationRef erence 
ap-title 

ap- i  n voca  t  i  on- i  d 
ae-qualif ier 
ae- i  nvoca  t  i  on- i  d 

: : =  SEQUENCE  { 

ISO-8650-ACSE-l.AP-title  OPTIONAL, 
ISO-86  50-ACSE-l.AP-invocation-id  OPTIONAL, 
ISO-8650-ACSE-l.AE-qualif ier  OPTIONAL, 
ISO-8650-ACSE-l.AE-invocation-id  OPTIONAL  } 

TO 

ApplicationRef erence 
ap-title 

ap- i  nvocat  i  on- i  d 
ae-qualif ier 
ae- i  nvocat  i  on- i  d 

: : =  SEQUENCE  { 

[0]  OBJECT  IDENTIFIER  OPTIONAL, 
[1]   INTEGER  OPTIONAL, 
[2]   INTEGER  OPTIONAL, 
[3]   INTEGER  OPTIONAL  } 

B.4.3       Page  95,  Section  12.2.1  of  DIS  9506-2 


CHANGE 

structure 

[2] 

IMPLICIT 

SEQUENCE 

OF  SEQUENCE  { 

TO 

structure 

[2] 

IMPLICIT 

SEQUENCE 

{ 

B.4.4       Page  96,  Section  12.3.1  of  DIS  9506-2 
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CHANGE 

named 

[4] 

IMPLICIT 

SEQUENCE 

{ 

TO 

named 

[5] 

IMPLICIT 

SEQUENCE 

{ 

B.4.5       Page  98,  Section  12.4.2  of  DIS  9506-2 


CHANGE 

general i  zed-t  ime 

[10] 

IMPLICIT 

General izedTime, 

TO 

general i  zed-t  ime 

[11] 

IMPLICIT 

General izedTime, 

B.4.6       Page  138,  Section  15.14  of  DIS  9506-2 


CHANGE 

additionalDetail 

[9] 

IMPLICIT  EE-Additional-Detail  OPTIONAL 

TO 

additionalDetail 

[9] 

EE-Additional-Detail  OPTIONAL 

B.4.7       Page  166,  Section  17.10  of  DIS  9506-2 


CHANGE  the  transfer  syntax  object  identifier  value  from 
{  iso    asnl(l)    basic-encoding( 1 )  } 


TO 

{  joint-iso-ccitt    asnl(l)     basic-encoding(l)  } 
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B.5.1  Filenames 

File  Names  are  specified  in  accordance  with  the  NBS  Implementors'  agreements  for  FTAM  Reference  [3] 
in  B.2. 


B.5.2       Identify  service 

In  the  Identify  service,  the  vendor,  model  and  revision  fields  may  be  of  any  length,  but  only  the  first  64,  16, 
and  16  octets  respectively  are  treated  as  significant. 


B.5.3       Initiate  service 

An  MMS  Client  will: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Called  parameter  in 
the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Calling  parameter  in  the 
Initiate  service  when  receiving  the  application  association  initiation  (called). 

An  MMS  Server  will: 

a)  propose  1  or  greater  for  the  value  of  the  Proposed  Max  Serv  Outstanding  Calling  parameter  in 
the  Initiate  service  when  initiating  the  application  association  (calling); 

b)  offer  1  or  greater  for  the  value  of  the  Negotiated  Max  Serv  Outstanding  Called  parameter  in  the 
Initiate  service  when  receiving  the  application  association  initiation  (called). 


B.5.3.1        Minimum  segment  size 

MMS  implementations  are  able  to  parse  and  process  512  octets  of  MMSpdu  as  they  are  encoded  in  ASN.1 
basic  encoding  rules. 


B. 5.3.2        Maximum  segment  size 

The  Max  Segment  Size  is  defined  as  the  maximum  number  of  octets  in  an  MMSpdu  encoded  using  the 
negotiated  transfer  syntax.  This  size  will  apply  to  all  MMSpdu's  with  the  exception  of  the  initiate-Request 
PDU,  initiate-Response  PDU,  and  the  initiate-Error  PDU.  The  max  segment  size  will  be  negotiated  during 
connection  initiation  using  the  Proposed  Max  Segment  Size  and  Negotiated  Max  Segment  Size  parameters 
•    of  the  MMS  initiate  service. 
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The  Max  Segment  Size  will  be  applied  as  follows: 


a)  Any  received  MMSpdu  which  is  less  than  or  equal  to  the  Max  Segment  Size  will  be  properly 
parsed  and  processed; 

b)  An  MMS  implementation  will  not  send  an  MMSpdu  whose  size  exceeds  the  Max  Segment  Size. 

B.5.4       Abstract  syntax  name 

The  ASN.1  object  identifier  value  for  the  abstract  syntax  name  will  be  the  same  as  specified  on  page  166, 
section  17.10  of  DIS  9506-2. 

B.5.5       Application  context  name 

The  ASN.1  object  identifier  value  for  the  application  context  name  will  be  the  same  as  specified  on  page  1 66, 
section  17.11  of  DIS  9506-2. 

An  MMS  implementation  ignores  the  Application  Context  Name  in  the  A-Associate  indication  and  the  A- 
Associate  confirm. 

B.5.6       Minor  version  number 

The  Minor  Version  Number  is  zero. 


B.6     Parameter  CBB  subset 

The  following  subset  of  MMS  Parameter  CBBs  were  considered  during  preparation  of  this  annex: 


a 


STR1; 


b) 


NEST; 


c) 


VADR; 


d) 


VNAM. 
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B.7     Service  subset 

The  following  subset  of  MMS  services  were  considered  during  preparation  of  this  annex. 

Table  2  -  MMS  Service  Subset 


Initiate 
Conclude 
Cancel 
Status 
GetNameList 
Identify 
UnsolicitedStatus 
GetCapabilityList 
InitiateDownloadSequence 

DownloadSegment 
TerminateDownloadSequence 
Ini  t  iateUploadSequence 

UploadSegment 
TerminateUploadSequence 
RequestDomainDownload 
Requ  e  s  t  Doma  i  nUp 1 cad 
LoadDoma  i  nCont  en t 
StoreDomainContent 

DeleteDomain 
GetDomainAt tributes 
Read 
Write 
InforitiationReport 
GetVariableAccessAt tributes 
Input 


Output 
TakeControl 
Re 11 nqui  shCont  rol 
ReportSemaphoreStatus 
ReportPoolSemaphoreStatus 
ReportSemaphoreEntryStatus 
CreateProgramlnvocat  ion 
DeleteProgramlnvocat  ion 
Start 
Stop 
Resume 
Reset 
Kill 

GetProgramlnvocationAt tributes 
ObtainFile 
GetEventConditionAt tributes 
Repor tEventCondi  t  ionStatus 
Get  Alarms  uitunary 
ReadJournal 
Wr  iteJournal 
Initialize Journal 
CreateJournal 
DeleteJournal 
Repor tJournalStatus 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture  (ODA) 
Special  Interest  Group  (SIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 
Development  of  this  document  application  profile  has  been  done  in  liaison  with  several  organizations.  These 
include  the  DoD  Computer-aided  Acquisition  and  Logistic  Support  (GALS)  Office,  Navy's  David  Taylor 
Research  Center,  and  the  ad-hoc  Tiling  Task  Group. 

This  document  application  profile  is  intended  to  be  suitable  for  the  interchange  of  large  format  raster  images 
which  may  be  annotated  with  character,  raster,  or  geometric  revisions. 

This  part  contains  four  annexes: 

a)  annex  A  (normative):  Amendments  and  Corrigenda; 

b)  annex  B  (informative):  Recommended  practices; 

c)  annex  C  (informative):  References  to  other  standards  and  registers; 

d)  annex  D  (informative):  Supplementary  information  on  attributes. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  22  -  ODA  Image  DAP 


0  Introduction 

This  is  tlie  definition  of  a  specification  for  an  Open  Document  Architecture  (ODA)  Document  Application 
Profile  (DAP)  named  ODA  Image  DAP.  This  DAP  is  suitable  for  interchanging  documents  in  formatted  form. 
The  documents  contain  primarily  raster  graphics  images  but  may  also  contain  character  and  geometric 
graphics  content  portions. 

There  are  two  DAP  object  identifiers  supporting  this  DAP  with  the  only  difference  being  in  the  encoding  of 
the  data  stream.  One  uses  the  ASN.1  based  ODIF  encoding.  The  other  uses  the  SGML/SDIF  based  ODL 
encoding.  When  this  document  refers  to  this  profile,  it  is  referring  to  this  specification  regardless  of  which 
DAP  identifier  may  be  selected  to  create  the  data  stream. 

The  DAP  is  defined  in  accordance  with  ISO  8613-1  and  CCITT  T.41 1  and  follows  the  standardized  proforma 
and  notation  defined  in  ISO  8613-1  Annex  F.  The  DAP  is  based  on  ODA  as  defined  in  ISO  8613  and  the 
Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 


1     Scope  and  Field  of  Applications 

This  DAP  specifies  an  interchange  format  suitable  for  transfer  of  structured  documents  between  equipment 
designed  for  raster  processing.  The  documents  supported  by  this  DAP  are  based  on  a  paradigm  of  an 
electronic  engineering  drawing  or  illustration.  Such  documents  contain  one  or  more  pages.  Each  page 
consists  of  a  base  image  in  the  form  of  a  bi-tonal  raster  graphics,  character,  or  geometric  graphics  content. 
This  base  image  may  be  further  annotated  with  character,  raster  graphics  or  geometric  graphics  content. 
These  latter  content  portions  sen/e  to  provide  revision  control  for  the  engineering  drawing  or  illustration. 
There  is  no  restriction  on  the  minimum  size  of  the  base  image. 

This  document  defines  a  DAP  that  allows  large  format  raster  documents  to  be  interchanged  in  a  formatted 
form  in  accordance  with  ISO  8613. 

It  is  assumed  that,  when  negotiation  is  performed  by  the  service  using  this  DAP,  all  non-basic  features  are 
subject  to  negotiation. 

This  DAP  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit,  or  reproduce  raster 
documents.  It  is  also  independent  of  the  means  to  transfer  the  document  which,  for  example,  may  be  by 
means  of  communication  links  or  exchanged  storage  media. 

The  features  of  a  document  that  can  be  interchanged  using  this  DAP  fall  into  the  following  categories: 

a)  Page  format  features  -  these  concern  how  the  layout  of  each  page  of  a  document  will  appear 
when  reproduced; 

b)  Raster  graphics  layout  and  imaging  features  -  these  concern  how  the  document  content  will 
appear  within  pages  of  the  reproduced  document;  and 

c)  Raster  graphics  coding  -  these  concern  the  raster  graphics  representations  and  control 
functions  that  make  up  the  document  raster  graphics  content. 
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Normative  References 


The  following  references  are  required  in  order  to  implement  this  DAP: 


2.1 


ISO 


[  1  ]       ISO  861 3-1  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interctiange  Format  -  Part  1:  Introduction  and  General  Principles; 

[2]       ISO  861 3-2  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Arcfiitecture 
(ODA)  and  Interctiange  Format  -  Part  2:  Document  Structures; 

[3]       ISO  861 3-4  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Arcfiitecture 
(ODA)  and  Interctiange  Format  -  Part  4:  Document  Profile; 

[4]       ISO  861 3-5  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Open  Document  Interchange  Format; 

[5]       ISO  861 3-6  :  1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  6:  Character  Content  Architecture; 

[6]       ISO  861 3-7  :  1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7:  Raster  Graphics  Content  Architectures; 

[7]       ISO  861 3-8 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  8:  Geometric  Graphics  Content  Architectures; 

[8]       ISO  861 3-1  : 1 991 ,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1  Annex  F  -  A  Document  Application  Profile  Proforma  and 


[9]  ISO  861 3-7  :  (to  be  published).  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Tiled  Raster  Graphics  Addendum 
to  ISO  8613,  Part  7; 

[10]  ISO  646  :  1990,  Information  processing  -  ISO  7-bit  coded  character  sets  for  information 
interchange; 

[11]  ISO  8859-1  :  1983,  Information  processing  -  8-bit  Single-byte  coded  graphic  character  sets  -  Part 
1:  Latin  alphabet  No.  1; 

[12]  ISO  6937-2  :  1983,  Information  processing  -  Coded  character  sets  for  text  communication  -  Part  2: 
Latin  alphabet  and  non-alphabetic  characters; 

[13]  ISO  2022  :  1986,  Information  processing  -  ISO  7-bit  and  8-bit  coded  character  sets  -  Code 
extension  techniques; 
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[14]      ISO  7350  :  1984,  Text  communication  -  Registration  of  graphic  character  subrepertoires, 

[15]      ISO  8824  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Abstract  Syntax  Notation  One  (ASM.  1); 

[16]      ISO  8825  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1); 

[17]      ISO  8879  :  1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGI^/IL)  ; 

[18]      ISO  9069  :  1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF). 


2.2  CCITT 

Transmission. 


[4ft|!|]  Recommendation  T.6  : 
4  Facsimile  Apparatus 


3     Definitions  and  Terminology 


3.1  Definitions 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 


3.2      Constituent  Names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  been  given  a  unique 
name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a  name 
are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  in  this  profile 
are  CompositePage,  DocumentLayoutRoot,  and  SpecificBlock. 


.  1988,  $mdardimtt<m  0/  Group  3  F&csfmih  App&mtus  for  Oocmm 
1 988,  Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group 


In  clause  6  of  this  profile,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text 
at  which  the  purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided 
by  this  profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  of  this  profile  so  that 
there  is  a  one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 
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Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents  must 
not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an  interchanged 
document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is  provided.  Thus  in 
an  application  using  this  profile,  the  constituents  may  be  known  to  the  user  by  different  names. 


4     Relationship  to  other  DAPs 

Functionally,  this  DAP  is  a  functional  superset  of  the  CCITT  Recommendation  T.503,  A  Document  Application 
Profile  for  the  Interchange  of  Group  4  Facsimile  Documents. 


5  Conformance 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document  must  meet  the  requirements 
specified  in  5.1. 

The  requirements  for  implementations  that  originate  and/or  receive  data  streams  conforming  to  this  DAP 
are  specified  in  5.2. 


5.1      Data  Stream  Conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that  conform  to  these  agreements: 

a)  The  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  In 
ISO  8825  or  the  SGML  encoding  rules  defined  in  ISO  8879; 

b)  The  data  stream  shall  be  structured  in  accordance  with  the  interchange  format  defined  in 
clause  8  of  this  DAP; 

c)  The  document  shall  be  structured  in  accordance  with  only  the  formatted  document 
architecture  class  specified  in  clause  7  of  this  DAP.  In  addition,  the  document  shall  contain  all 
mandatory  constituents  specified  for  that  class  and  may  optionally  contain  constituents 
permitted  for  that  class  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that  constituent  in 
this  profile.  Other  attributes  may  be  specified  provided  they  are  permitted  for  that  constituent; 

e)  The  attributes  shall  have  values  within  the  range  of  permissible  values  specified  in  this  profile; 

f)  The  encoded  document  shall  be  structured  in  accordance  with  the  abstract  document 
architecture  defined  in  ISO  8613-2; 

g)  The  encoded  document  shall  be  structured  in  accordance  with  the  characteristics  defined  in 
clause  6  of  this  DAP  and  shall  contain  only  those  features  defined  in  clause  6. 


4 


PART  22  -  ODA  Image  DAP 

5.2      Implementation  Conformance 


June  1992  (Stable) 


This  clause  states  the  requirements  for  implementations  claiming  conformance  to  this  DAP. 

A  conforming  receiving  implementation  must  be  capable  of  receiving  either  any  data  streams  conforming 
to  this  profile  structured  in  accordance  with  ODIF  or  any  data  streams  conforming  to  this  profile  structured 
in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements. 


6     Characteristics  Supported  by  this  DAP 

This  clause  describes  the  characteristics  of  documents  that  can  be  represented  by  data  streams  conforming 
to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in  terms  of  divisional 
components  of  the  data  streams. 


6.1  Overview 

This  DAP  describes  the  features  of  ISO  8613  that  are  needed  to  support  the  interchange  of  documents 
containing  images.  It  specifies  interchange  formats  for  the  transfer  of  structured  documents  with  simple 
layout  structures. 

This  DAP  describes  documents  that  can  be  interchanged  in  the  formatted  form,  which  facilitates  the 
reproduction  of  a  document  as  intended  by  the  originator. 

The  content  within  the  document  forming  the  original  or  base  image(s)  may  be  formatted  processable  raster 
graphics,  formatted  processable  geometric  graphics,  and/or  formatted  character.  This  is  intended  to 
facilitate  the  reproduction  of  the  document  content  as  intended  by  the  originator  or  allows  the  reformatting 
of  the  document  content. 

The  content  allowed  within  the  document  to  annotate  revisions  to  the  base  image(s)  may  also  be  formatted 
processable  raster  graphics,  formatted  processable  geometric  graphics,  and/or  formatted  character. 

This  clause  describes  the  layout  features  that  can  be  represented  in  documents  conforming  to  this  DAP. 
The  features  are  described  in  terms  that  are  typical  of  the  user-perceived  capabilities  and  semantics  found 
in  a  raster  document  interchange  environment. 

For  the  purpose  of  interchange,  a  document  is  represented  as  a  collection  of  constituents,  each  of  which 
is  represented  by  a  set  of  attributes.  The  constituents  that  make  up  a  formatted  document  are  defined 
below  in  this  clause  and  are  illustrated  in  figure  1. 
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Document  Profile 


Generic  Layout 
Structure  (Optional) 


Presentation  Style 
(Optional ) 


Specific  Layout 
Structure 


Content  Portion 
Description 


Figure  1  -  Constituents 

Constituents  defined  as  required  must  occur  in  any  document  tliat  conforms  to  this  profile.  Constituents 
listed  as  optional  may  or  may  not  be  present  in  the  document,  depending  on  the  requirements  of  the 
particular  document. 

The  required  constituents  include: 

a)  a  document  profile; 

b)  layout  object  descriptions  representing  a  specific  layout  structure; 

c)  content  portion  description. 

The  only  optional  constituents  are  presentation  style  and  generic  layout  structure. 


6.2      Logical  Constituents 

Not  applicable. 


6.3      Layout  Constituents 

This  clause  describes  the  features  of  the  layout  objects  that  can  be  represented  in  documents  conforming 
to  this  DAP. 


6.3.1       Overview  of  the  Layout  Characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  pages. 
Each  page  in  a  document  may  consist  of  a  single  raster  graphics  content.  This  would  be  the  case  for  an 
original  image  of  an  engineering  drawing,  illustration,  or  other  raster  scanned  image.  Optionally,  each  page 
in  a  document  may  consist  of  an  original  image  which  contains  raster  graphics,  geometric  graphics,  and /or 
character  content,  with  additional  character,  raster  graphics  or  geometric  graphics  content,  representing  a 
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set  of  revision  annotations  of  the  original  image. 

A  specific  layout  structure  of  the  document  conforming  to  this  application  profile  consists  of  a  four-level 
hierarchy  consisting  of  a  document  layout  root,  composite  pages,  frames,  and  blocks.  The  document  can 
consist  of  multiple  composite  pages  where  each  page  represents  a  single  image  including  any  revision 
annotations.  The  composite  pages  consist  of  frames  which  in  turn  contain  blocks  containing  the  content 
associated  with  the  base  image  and  the  revision  annotation. 

Figure  2  is  an  illustration  of  the  features  of  the  document  layout  structure  supported  by  this  DAP. 


Document 
Layout 
Root 


Composite 
Pages (s) 


Original 
Image 
Frame 


Revision 
Annotation 
Frame(s) 


Specific 
Block(s) 


Specific 
Block 


Figure  2  -  Document  layout  structure 


6.3.2  DocumentLayoutRoot 

A  DocumentLayoutRoot  is  the  top  level  in  a  document  layout  structure.  A  DocumentLayoutRoot  consists 
of  a  sequence  of  one  or  more  CompositePage  constituent  constraints. 


6.3.3       Page  Characteristics 

Only  one  constituent  constraint  is  provided  to  present  pages  within  a  document. 

A  document  consists  of  a  sequence  of  one  or  more  composite  pages.  In  a  document's  composite  page, 
two  types  of  frames  are  used  to  position  content  information  on  the  page.  One  frame  type  is  used  to 
position  the  content  representing  the  original  image  on  the  page.  Only  one  frame  of  this  type  is  allowed  per 
page,  but  it  may  contain  any  number  of  raster  graphics,  geometric  graphics,  or  character  content  portions. 
The  second  frame  type  is  used  to  position  a  character,  raster  graphics  or  geometric  graphics  content 
representing  a  revision  annotation  on  the  page.  There  may  be  one  or  more  of  the  frames  containing  a 
revision  annotation. 
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A  document  may  consist  of  multiple  pages  of  different  sizes.  Each  page  may  be  either  landscape  or  portrait 
orientation.  Both  orientations  are  permitted  in  the  document. 


6.3.3.1  CompositePage 

A  CompositePage  is  a  constituent  constraint  which  defines  a  composite-page  that  corresponds  to  the  page 
area  used  for  presenting  the  sequence  of  an  Originalimage  frame  and  zero  or  more  RevisionAnnotation 
frames. 


6.3.3.2        Page  Dimensions 

A  wide  variety  of  page  dimensions  are  supported  including  large  format  raster  documents.  The  dimensions 
of  the  pages  may  be  specified  as  any  value,  in  BMU  measurement  units,  including  the  larger  sizes  produced 
from  foldout-size  images  and  roll  paper.  These  sizes  apply  to  both  portrait  and  landscape  orientations.spie 

page  sizes  include:  ISO  A0-A5,  ANSI  A-K,  Japanese  lega!  and  tetter,  {oidouts  27.94  cm  (1 1  in.)  X  34.56  cm 
<14  ia)  and  27<94  cm  (1 1  in.)  X  43,18  cm  (17  in,),  and  27.94  cm  (1 1  in.)  roll  paper 

DimonGiono  oquivalont  to  or  loso  than  the  actual  (nominal)  page  oizoo  of  ANSI  E  in  both  portrait  and 
landocapo  oriontations  arc  basic  valuos.  Larger  dimonoiono  (F  K)  including  those  produced  from  roll  paper 
arc  non  baoio  and  their  uoo  must  bo  indicated  in  the  document  profile.  Although  ISO  AO  A4  sizes  are  not 
generally  used,  the  A1  A4  oizoo  do  fall  within  the  range  of  the  ANSI  E  oizos  and  therefore  could  bo 
oonoidorod  baoio  valuoo  (Soo  tablo  2).  AO  oizo  io  a  non  basic  valuo. 

Dfmertsions  equivalent  to  or  less  than  the  common  assured  reproduction  area  of  ISO  A4  and  North  American 
Letter  (NAL)  in  portrait  or  landscape  orientation  are  basic  values.  Larger  page  si20$  IttCltiding  those 
produced  from  roll  paper  are  non-tsasic  and  their  use  must  be  indicated  in  the  docurDent  profila  (See  table 

m 

The  default  dimensions  are  the  Common  Assured  Reproduction  Area  (CARA)  of  North  American  Letter  (A). 
Any  default  page  dimensions  may  be  specified  in  the  document  profile  subject  to  the  maximum  dimensions 
defined  above  by  using  the  Page-dimensions  attribute.  The  Page-position  attribute  may  be  used  to  specify 
the  position  of  the  pel  array  image  on  the  page.  Although  actual  page  dimensions  may  be  used  allowing 
for  the  raster  content  to  completely  fill  a  page  leaving  no  borders,  it  is  advised  that  the  assured  reproduction 
area  (ARA)  listed  in  table  1  be  used  wherever  feasible.  See  7.3  of  ISO  8613-2  for  general  rules  for 
positioning  pages  on  presentation  surfaces. 


6.3.3.3        Nominal  Page  Sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1 .  In  addition,  i  1  mch  roll  paper  of  any 
l^rigth  is  supported.  These  may  be  specified  in  portrait  or  landscape  orientations.  All  valuoo  of  nominal 
page  oizo  up  to  ANSI  E  oizo  aro  baoic.  All  oizoo  larger  than  ANSI  E  oizo  and  roll  paper  arc  non  baoio  and 
their  uoo  in  a  document  must  bo  indicated  in  the  deeumont  profiio  uoing  the  Medium  typo  attribute  (Soo 

table  2).  Ail  values  of  nominal  page  size  are  non-basic  and  hence  all  values  used  in  a  documeRt::;rutist:;;b.e 
indicated  In  the  document  profile  (See  table  2)i 

Any  of  the  nominal  page  sizes  defined  in  table  1 ,  subject  to  the  restriction  specified  above,  may  be  specified 
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Table  1  also  includes  the  recommended  assured  reproduction  area  (ARA).  Information  loss  may  occur  when 
a  document  is  reproduced  if  the  dimensions  of  the  CompositePage  exceed  the  ARA  for  the  specified 
nominal  page  size. 


6.3.4  Originalimage 

An  Originalimage  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the 
original  image  of  an  engineering  drawing,  illustration  or  other  image.  This  frame  contains  one  or  more 
SpecificBlocks  each  of  which  may  contain  one  of  a  character  content  portion,  a  raster  graphics  content 
portion,  or  a  geometric  graphics  content  portion.  Note  that  there  must  be  exactly  one  Origninallmage  frame 
on  each  page. 

This  type  of  frame  has  a  fixed  position  and  dimensions.  The  position,  if  not  specified,  defaults  to  the  origin 
of  the  page.  The  dimensions,  if  not  specified,  default  to  the  maximum  size  that  can  be  achieved  for  the 
position  within  the  area  of  the  page. 


6.3.5  RevisionAnnotation 

A  RevisionAnnotation  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the 
revision  annotation  associated  with  the  original  image.  This  frame  contains  a  single  SpecificBlock  containing 
either  a  character  content  portion,  a  raster  graphics  content  portion  or  a  geometric  graphics  content  portion. 

This  type  of  frame  has  a  fixed  position  and  dimensions.  This  provision  provides  for  the  capability  of 
positioning  of  revision  annotation  anywhere  on  the  page.  Registration  of  revision  annotation  over  a  portion 
of  the  original  image,  as  in  revision  artwork,  is  accomplished  using  this  capability. 


6.3.6  SpecificBlock 

A  SpecificBlock  is  a  constituent  constraint  which  defines  a  basic  layout  object  used  to  position  and  image 
the  content  portions  associated  with  either  an  Originalimage  or  RevisionAnnotation  frame. 

The  position  of  the  block  is  fixed  and  defaults  to  the  origin  of  the  superior  frame.  The  dimensions  default 
to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area  of  the  superior  frame. 


6.3.7  GenericBlock 

GenericBlock  is  a  constituent  constraint  which  defines  a  layout  object  class  which  can  define  content  that 
is  common  and  can  be  referenced  throughout  the  document.  Any  content  type  (raster,  character,  or 
geometric  graphics)  can  be  defined  using  this  technique. 
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Table  1  Dimensions  for  various  page  sizes 


Page  type 

Size 

Size  (BMU) 

ARA  (BMU) 

-  Metric 

IS0-A5 

148mm  x  210mm 

7015  X  9920 

not  defined 

IS0-A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

IS0-A3 

297mm  X  420mm 

14030  X  19840 

13200  X  18480 

IS0-A2 

420mm  X  594mm 

19840  x  28060 

18898  X  27118 

IS0-A1 

594mm  x  841mm 

28060  x  39680 

26173  X  37843 

ISO-AO 

841mm  x  1189mm 

39680x56120 

37843  X  54283 

-  ANSI,  North  American  (NA) 

NA-A 

8.5in  X  Ilin 

10200  X  13200 

9240  X  12400 

NA-B 

11in  x  17in 

13200  X  20400 

12744  X  19656 

NA-C 

17in  X  22in 

20400  X  26400 

19500  X  25800 

NA-D 

22in  X  34in 

26400  x  40800 

25800  X  39600 

NA-E 

34in  X  44in 

40800  x  52800 

39600  X  52200 

NA-F 

28in  X  40in 

33600  X  48000 

32400  X  47400 

NA-G 

1 1  in  X  90in 

13200  X  108000 

12400  X  106800 

NA-H 

28in  X  143in 

33600  X  171600 

31400  X 170400 

NA-J 

34in  X  176in 

40800x211200 

39600  x  210000 

NA-K 

40in  X  143in 

48000  X  171600 

47400  X  170400 

NA-Legal 

8.5in  X  14in 

10200  X  16800 

9240  X 15480 

-  Foldouts 

Small 

Ilin  X  14in 

13200  X  16800 

12744  X  15480 

NA-B 

11in  X  17in 

13200  X  20400 

12744  X  19656 

11200  X  15300 

257mhr»  i(:  3BAmti 

12141  X  17196 

Listter 

^82mhti  X  2S7rnrn 

8598  X  12141. 

7600 X  10200 

Tutorial  Note  -  These  page  sizes  are  for  the  portrait  orientation. 
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Table  2  Layout  attributes 


Attributes 

Basic  values 

Default 
values 

Non-basic 
values 

Page  dimensions  ** 

CARA  NA  A  F> 
CARA  MA  Logal, 
ISO  A1, 
Small  Foldout 
CARA  m  A, 
ISO  A4 

CARA  NA-A 

ARA  NA  GB-K, 
ISO  AOmlpp 

11*  Rolll^pir 

Medium-type  ** 
(Nominal  page  size) 

NA  AF. 
NA  Legal, 
ISO  Al  A1> 
Small  Foldout 
None 

iHi 

NA  G^K, 

ISO  ACKAS, 
Japan  tetter  & 

11"  fRoll  Paper 

Tutorial  Note  -  See  table  1  ** 


6.4      Document  Layout  Characteristics 

This  DAP  provides  for  only  formatted  documents.  Hence,  no  provision  is  made  for  constraining  the 
document  layout  process  other  than  as  implied  in  the  formatted  documents  supported  by  this  DAP.  In 
particular,  these  formatted  documents  are  characterized  by  the  following: 

a)  Documents  containing  only  composite  pages; 

b)  Documents  may  contain  one  or  more  pages; 

c)  Pages  may  vary  by  orientation  within  a  document; 

d)  As  a  minimum,  each  page  contains  a  single  raster  graphics,  geometric  graphics,  or  character 
content  portion,  representing  the  original  image; 

e)  Each  page  may  additionally  contain  one  or  more  character,  raster  graphics  or  geometric 
graphics  content  portions  representing  revision  annotation; 

f)  Content  is  positioned  within  fixed  position  and  dimension  frames. 
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6.5      Content  Layout  and  Imaging  Control 

A  document  is  modelled  as  an  original  image  with  optional  revision  annotation (s).  The  original  image  and  . 
the  revision  annotation(s)  may  be  represented  by  either  character,  raster  graphics,  or  geometric  graphics  ' 
content  portions,  as  specified  in  ISO  8613-6,  ISO  8613-7  and  ISO  8613-8,  respectively. 

The  content  architectures  that  may  be  specified  using  the  attribute  Content  architecture  class  are  formatted 
character,  formatted  processable  raster  graphics  and  formatted  processable  geometric  graphics.  The 
formatted  prooossablo  raster  graphics  is  tho  only  oontont  that  Any  of  th0  db(W0  <K;»it0nl$  may  be  specified 
as  the  default  in  the  document  profile. 

6.5.1       Raster  Graphics  Content 

6.5.1.1  introduction 

This  clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content. 
The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

a)  type  of  coding  (required); 

b)  compression; 

c)  pel  path; 

d)  line  progression; 

e)  pel  spacing; 

f)  spacing  ratio; 

g)  clipping. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  or  coding  attribute  must  be 
indicated  in  the  document  profile. 

6.5.1 .2  Raster  Graphiics  Content  Architecture 

The  formatted  processable  raster  graphics  content  architecture  is  supported  by  this  DAP  and  will  frequently 
be  the  primary  content  architecture  in  a  document.  This  is  tho  only  default  content  arohitocturo  olaco  that 
can  bo  specifiod  in  tho  dooumont  profile. 

In  a  composite  page,  multiple  content  portions  may  be  associated  with  the  original  image,  whereas  only  one 
content  portion  may  be  associated  with  a  given  revision  annotation. 
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6.5.1.3        Raster  Graphics  Encoding  Methods 

Throo  onooding  mothodc,  CCITT  T.6  (untilod).  Tiled,  and  Bitmap  arc  oupportcd  by  thio  profile  ao  baoio 
valuoc. — Neither  the  CCITT  T.'l  one  dimenoional  method  nor  the  CCITT  T.4  two  dimenoional  method  io 
supported. 

The  CCITT  Rooommondation  T.6  Group  A  oomproosion  algorithm  shall  bo  uood  in  all  oaooo,  tiled  and  untilod, 
oxoopt  where  it  is  more  offioiont  to  retain  an  image  or  ti!e  image  in  bitmap  format  or  to  opooify  a  tile  ao  being 
cithor  all  background  or  all  foreground. 

Th&  J5c»««rtt^.^^.«^  encoding  schemes  d0fliied'''W'''OTT| 

R«onE»T)erKlialR»is  T*4  md  T<6<  tn  tlie  case  of  T<4,  either  the  one-dimensional  or  two  dimensional  encoding 
S<^r»eim«y  tse  u$0d^  ^SOthe^blt-fliap  encoding'  scheme  defined  in  ISO  8613-7  may  be  used.  All  these 
forms  moo6ing  may  be  used  in  a  ^gte  document  and  all  are  basic  values.  Uncompressed'  mode  of 
encoding  may  also  be  used  but  only  as  a  non-basic  feature. 

In  a  content  portion,  it  io  required  that  the  Numbor  of  pels  per  line  and  Number  of  lines  parametero  of  the 
Coding  attributes  attributes  be  opooifiod. — The  value  of  theoe  parameters  shall  bo  a  pooitivo  numbor. 
Otherwise,  no  constraints  are  placed  on  these  parameters  by  thio  profile.  In  a  content  portion,  It  Is  required 
thai tJ»: coding  attribute  "number-of-pels-per-line"  is  specified.  The  coding  attribute  "number-of4ines''  may 
^SO  be  speckled.  No  restriction  Is  placed  on  the  values  that  may  be  specified  for  these  coding  attributesi 
This  proifile  places  no  constraints  on  the  size  of  the  pel  arrays  that  may  be  used  as  long  as  the  size  doos 
not  exceed  the  page  dimension  oizo. 

The  type  of  coding  method  used  is  specified  by  the  attribute  fType-of-coding".  The  use  of  this  attribute  is 
mandatory  in  the  Document-architecture-defaults  of  the  document  profile  to  define  the  default  value  of  either 
T.6  encoding  (untiled)  or  Tiled  encoding.  The  use  of  this  attribute  in  the  description  of  the  content  portions 
is  non-mandatory.  If  this  attribute  is  not  specified  for  a  particular  content  portion,  then  the  default  value 
specified  in  the  Document-architecture-defaults  of  the  document  profile  is  used. 

If  the  Tiled  encoding  method  is  used,  the  default  value  of  512  for  the  |N|umber-of-pels-per-tile-lines  and 
|N|umber-of-lines-per-tile|  must  be  used.  No  other  values  are  supported,  therefore  these  two  attributes  do 
hot  need  to  be  specified.  If  the  |Tile-types|  attribute  is  not  present,  then  all  tiles  will  be  T.6  encoded.  If  it 
is  present,  then  there  must  be  a  value  specified  for  each  tile  in  which  case  only  null  background,  null 
foreground,  T.6  encoded,  or  bitmap  encoded  values  are  supported.  T.4  one  dimensional  and  T.4  two 
dimensional  encodings  are  not  supported.  There  are  no  restrictions  on  the  use  of  the  Tiling-offset  other  than 
that  specified  in  ISO  8613-7  Addendum. 

See  table  D.I,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.1.4        Raster  Presentation 

Raster  presentation  is  controlled  by  the  presentation  attributes  specified  in  ISO  8613-7.  This  DAP  provides 
for  additional  constraints  on  these  presentation  attributes  as  specified  below. 

The  basic  Pel-path  values  supported  by  this  profile  are  0  and  90  degrees.  The  Pel-path  values  of  180  and 
270  degrees  are  non-basic. 
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The  basic  Line-progression  value  supported  by  this  profile  is  270  degrees.  The  Line-progression  value  of 
90  degrees  is  non-basic. 

The  baoio  Pol  spacing  values  oupportod  by  this  profile  aro  the  ratioo  equal  to  6  and  4  BMUo  botwoon 
adjacent  polo. — This  corroopondo  to  cquivalont  roGolutions  of  200  and  300  polo  per  26.4  mm  (1  in.), 
roGpoctivoly  when  the  BMU  is  intorprotod  as  1  /1200  inch.  Valuoo  for  Pol  spacing  other  than  thooo  ratios  aro 
non  basic,  i.e.,  6,  3,  2,  and  1  BMU.  Those  correspond  to  cquivalont  rooolutiono  of  240,  400,  600,  and  1200 
pols  por  26.4  mm  (1  in.). 


1  BMU.  Th$  pei  $p«icing  need     be  an  Integer  value.  The  value 

Of  'null'  may 

not  be 

f  Specified 

b^u$s 

the  scalable  layout  process 

is  not  supported.  The  specification  of 

the  spadngs 

of 

te.  12.  8. 6.  5, 4. 3. 

a, 

isrid  i  t  BMU  between  adlacent  peis  ^re  basic  The  $peciflcaitlon  of  ^ny  oilier  spacing 

1$  t 

non-basic  3 

ind 

be  specified  In  the  document  pr ofUa 


NOTES 


1  Th$  fc>a$tc  pel  spadrtQ  vaiue$  listed  s^ove  are  ecjuivatent  to  re$otutbn$  of  75, 100, 150^  200, 240, 300, 400» 

$00,  and  1200  pels  per  25.4mm  respectively  when  the  BMU  ts  interpreted  as  1/1200  irKfe 

2  The  attribute  "pet  spacing*'  specifies  two  integers,  the  raHo  Of  which  determined  th*      spScsng*  NO 

restrtction  is  placed  on  the  values  of  these  integersi 


There  are  no  restrictions  on  the  use  of  the  Clipping  attribute.  The  Image-dimensions  attribute  is  not 
supported. 


There  are  no  restrictions  placed  on  the  value  of  the  Spacing-ratio  providing  that  the  resultant  line  spacing 
is  not  less  than  1  BMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  BMUs.  All  values  are 
basic. 


See  table  D.2,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.2       Character  Content 


The  formatted  character  content  is  permitted  in  this  DAP  for  use  in  either  the  original  image  or  in  revision 
annotations  of  that  original  image. 

The  specification  in  a  document  of  a  non-basic  feature  by  a  presentation  attribute  or  control  function  must 
be  indicated  in  the  document  profile. 


6.5.2.1        Character  Content  Architecture  Class 

When  using  character  content,  only  one  content  portion  may  be  associated  with  a  basic  component.  The 
content  information  in  a  content  portion  must  be  present. 
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6.5.2.2        Character  Repertoires 

The  basic  character  set  supported  by  this  profile  is  the  primary  character  set  of  ISO  8859-1.  This  must  t>e 
designated  to  the  GO  set  and  invoked  to  the  GL.  Any  other  graphic  character  set  which  is  registered  In 
accordance  with  ISO  2375  may  be  designated  and  invoked  at  any  point  In  the  document  provided  its  use 
is  announced  in  the  document  profile  as  a  non-basic  value  using  the  character  presentation  attribute  Graphic 
character  sets.  No  locking  shift  functions  are  specified  in  this  presentation  attribute.  The  default  graphic 
character  sets  which  apply  to  the  content  portions  within  a  document  can  be  specified  in  the  document 
profile  using  the  presentation  attribute  graphic  character  sets. 

Using  code  extension  techniques,  the  graphic  character  sets  designated  and/or  invoked  at  the  beginning 
of  a  content  portion  containing  character  content  are  specified  using  the  presentation  attribute  graphics 
character  sets. 

If  the  character  set  defined  in  ISO  6937-2  is  designated  and  invoked,  then  the  use  of  any  sub-repertoire 
registered  according  to  ISO  7350  may  be  specified.  All  sub-repertoires  are  non-basic  and  their  use  must 
be  indicated  in  the  document  profile. 


6.5.2.3         Code  Extension  Techniques 

The  code  extension  techniques  specified  in  ISO  2022  may  be  used  subject  to  the  following  restrictions: 

a)  GO  set:  only  the  primary  character  sets  of  ISO  6937-2,  ISO  8859-X  (where  ISO  8859-X 
corresponds  to  any  finalized  part  of  ISO  8859)  and  a  version  of  ISO  646  may  be  designated  for 
this  set;  these  character  sets  may  only  be  invoked  in  GL; 

b)  G1,  G2,  G3  sets:  no  restrictions  are  placed  on  the  character  sets  that  may  be  designated  for 
these  sets;  these  sets  may  only  be  invoked  in  GR; 

c)  The  locking  and  single  shift  functions  allowed  should  be  restricted  to  the  following: 

LSO  for  the  GO  set 
LS1R  for  the  G1  set 
LS2R  for  the  G2  set 
LS3R  for  the  G3  set 
SS2 
SS3; 

d)  When  specifying  the  presentation  attribute  Graphic  character  sets,  it  is  necessary  to  invoke 
character  sets  for  both  GL  and  GR.  Thus  an  allowed  character  set  must  be  designated  into  GO, 
as  specified  above,  and  invoked  into  GR.  It  is  also  necessary  to  invoke  a  character  set  into  GR 
which  has  been  designated  into  G1,  G2  or  G3  sets; 
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e)  The  empty  set  should  be  designated  and  invoked  in  GR  if  no  other  specific  set  is  invoked 
into  GR. 

The  announcement  and  encoding  of  these  functions  are  to  be  as  specified  in  ISO  2022. 


6.5.2.4         Line  Spacing 

Any  value  of  line  spacing  may  be  specified.  Values  of  150,  200,  300  and  400  BMUs  are  basic;  the  use  of 
any  other  value  in  a  document  is  non-basic  and  must  be  indicated  in  the  document  profile.  The  line  spacing 
may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component  using  the  presentation 
attribute  "Line  spacing".  The  value  may  be  changed  anywhere  within  the  content  portion  using  the  control 
functions  SVS  and  SLS. 


6.5.2.5        Character  Spacing 

Any  value  of  character  spacing  may  be  specified.  Values  greater  than  or  equal  to  100  are  basic;  the  use 
of  any  other  value  in  a  document  is  non-basic  and  must  be  indicated  in  the  document  profile.  The  character 
spacing  may  be  specified  at  the  beginning  of  the  content  associated  with  a  basic  component  using  the 
attribute  "Character  spacing".  The  value  may  be  changed  anywhere  within  a  content  portion  using  the 
control  functions  SHS  or  SCS. 


6.5.2.6        Character  Path  and  Line  Progression 

Both  horizontal  and  vertical  writing  directions  may  be  used  within  a  character  content.  In  the  case  of 
horizontal  writing,  the  characters  progress  either  from  left  to  right  or  from  right  to  left  across  the  page  and 
the  line  progression  is  from  the  top  of  the  page  to  the  bottom.  In  the  case  of  vertical  writing,  the  characters 
progress  from  the  top  of  the  page  to  the  bottom  and  the  line  progression  is  from  the  right  to  the  left.  The 
values  of  character  path  and  line  progression  may  be  specified  at  the  beginning  of  the  content  associated 
with  a  basic  component  using  the  presentation  attributes  Character  path  and  Line  progression,  respectively. 
These  values  cannot  be  changed  within  a  content  portion. 


6.5.2.7        Character  Orientation 

The  character  orientation  may  be  specified  as  0  or  90  degrees  depending  on  whether  vertical  or  horizontal 
writing  is  used.  When  vertical  writing  is  used,  characters  are  normally  orientated  at  0  degrees.  When 
horizontal  writing  is  used,  characters  may  be  orientated  at  0  or  90  degrees.  A  value  of  0  degrees  is  basic; 
a  value  of  90  degrees  is  non-basic  and  its  use  in  a  document  must  be  indicated  in  the  document  profile. 
The  value  of  the  character  orientation  is  specified  at  the  beginning  of  the  content  associated  with  a  basic 
component  by  the  presentation  attribute  Character  orientation.  This  value  cannot  be  changed  within  the 
content. 
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6.5.2.8  Emphasis 

The  following  modes  of  emphasising  graphic  characters  may  be  distinguished: 


a) 

normal  rendition; 

b) 

normal  intensity; 

c) 

Increased  intensity  (bold); 

'J/ 

itfllipicpH' 

e) 

not  italicised; 

f) 

underlined; 

g) 

doubly  underlined; 

h) 

not  underlined; 

i) 

crossed-out; 

j) 

not  crossed-out. 

All  the  above  modes  of  emphasis  are  basic.  If  no  default  mode  is  explicitly  specified  in  the  document  profile, 
then  the  default  mode  is  normal  rendition.  The  mode  of  emphasis  may  be  specified  at  the  beginning  of  the 
content  associated  with  a  basic  component  using  the  presentation  attribute  Graphic  rendition.  The  mode 
may  be  changed  anywhere  within  the  content  using  the  control  function  SGR.  The  mode  of  emphasis 
remains  in  effect  within  the  content  associated  with  a  basic  component  until  changed  into  a  mutually 
exclusive  mode  or  by  the  specification  of  normal  rendition.  Mutually  exclusive  modes  are  normal/increased 
intensity,  italicized/not  italicized,  underlined/not  underlined  and  crossed  out/not  crossed-out.  One  mode 
from  each  mutually  exclusive  set  may  be  in  operation  at  any  point  in  the  document  content.  Normal 
rendition  cancels  the  effect  of  all  methods  of  emphasis  that  are  currently  in  operation  and  specifies  that  the 
text  should  be  displayed  in  accordance  with  the  default  rendition  parameters  set  for  the  presentation  device. 
Thus,  for  example,  if  it  is  required  to  ensure  that  the  content  is  not  underlined,  then  it  is  necessary  to 
explicitly  specify  that  underlined  is  not  to  be  used. 


6.5.2.9  Tabulation 

Tabulation  stop  positions  may  be  specified  at  any  character  position  along  the  character  path.  Each  stop 
is  specified  by  means  of  the  following: 

a)  The  tabulation  position  relative  to  the  margin  position  in  the  direction  opposite  to  the 
character  path; 

b)  An  alignment  qualifier  that  specifies  the  type  of  alignment  to  be  used  at  the  designated 
tabulation  position.  The  type  may  be  specified  as  one  of  the  following: 
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start  aligned; 


end  aligned; 


centered; 


aligned  around. 


These  alignment  qualifiers  are  defined  in  ISO  861 3-6.  If  the  alignment  qualifier  is  not  explicitly  specified,  then 
it  is  assumed  that  start  aligned  is  to  be  used.  Only  one  set  of  tabulation  stops  can  be  specified  to  be 
applicable  to  the  content  associated  with  a  basic  component.  No  limit  is  placed  on  the  number  of  tabulation 
stops  that  can  be  specified  within  a  given  set.  The  set  of  tabulation  stop  positions  associated  with  the 
content  of  a  basic  component  are  specified  using  the  presentation  attribute  Line  layout  table.  Tabulation 
stop  positions  are  invoked  within  the  content  using  the  control  function  STAB. 


6.5.2.10  Alignment 

This  feature  is  concerned  with  how  the  first  and  last  characters  on  each  line  of  character  content  Is  to  be 
laid  out  during  the  formatting  process.  The  following  values  of  alignment  may  be  specified: 

a)  start  aligned; 

b)  end  aligned; 


The  semantics  of  these  values  are  as  defined  in  ISO  8613-6.  The  presentation  attribute  >V/gfnme/7f  is  used 
to  specify  the  alignment  that  is  applicable  to  the  content  associated  with  a  basic  component.  The  alignment 
value  cannot  be  changed  within  a  content  portion. 


6.5.2.11  Fonts 

Any  number  of  fonts  may  used  within  a  document.  The  fonts  used  in  a  particular  document  are  specified 
in  the  document  profile  using  the  attribute  Font  list.  Further  information  concerning  the  specification  of  font 
references  in  the  document  profile  is  given  in  Annex  B.  The  fonts  that  may  be  used  within  the  content 
associated  with  each  basic  component  are  specified  by  the  presentation  attribute  Character  fonts.  Up  to 
10  fonts  taken  from  the  list  specified  by  the  attribute  Font  list  may  be  specified  by  the  attribute  Character 
fonts.  The  font  to  be  used  at  the  start  of  the  content  associated  with  a  basic  component  is  specified  using 
the  attribute  Graphic  rendition.  The  fonts  used  within  the  content  may  be  changed  using  the  control 
function  SGR. 


c) 


centred; 


d) 


justified. 
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Bi-directional  writing  is  supported  by  this  profile.  Hence,  a  string  of  characters  in  a  content  portion 
associated  with  a  basic  component  may  be  specified  to  be  imaged  in  the  reverse  direction  of  the 
immediately  preceding  character  string.  Such  strings  can  be  specified  by  the  control  function  SRS  as 
defined  in  ISO  8613-6.  This  control  function  is  provided  for  cases  in  which  the  text  t>elongs  to  different 
languages  and  the  character  content  is  written,  for  example,  from  left  to  right  or  from  right  to  left  within  the 
same  line  of  characters,  dependent  upon  the  language  and/or  character  set  being  used. 

NOTE  -  The  use  of  this  control  function  cannot  be  indicated  in  the  document  profile.  Thus  it  is  intended  that 
implementations  should  ignore  this  control  function  when  reverse  character  string  layout  and  presentation  is 
not  supported. 


6.5.2.13       Superscripts  and  Subscripts 

Superscripts  and  subscripts  may  be  specified  anywhere  within  the  content  associated  with  a  t)asic 
component  by  using  the  control  functions  PLU  and  PLD.  The  use  of  these  control  functions  shall  be  in 
accordance  with  ISO  8613-6. 


6.5.2.14       Substitution  of  Characters 

The  control  function  SUB  is  provided  to  represent  characters  produced  by  a  local  system  that  cannot  be 
represented  by  a  character  within  a  character  set  supported  by  this  profile. 


6.5.2.15       Use  Of  Control  Functions 

The  following  is  a  list  of  all  the  control  functions  and  parameter  values  (where  applicable)  that  may  be 
specified  in  character  content: 


a) 

SHS 

-  set  horizontal  spacing; 

b) 

SOS 

-  set  character  spacing; 

c) 

SVS  ■ 

■  set  vertical  spacing; 

d) 

SLS  ■ 

set  line  spacing; 

e) 

SGR 

-  set  graphic  rendition; 

f) 

STAB 

-  selective  tabulation  (allowed  parameter  values:  any) 

g) 

SRS 

-  start  reverse  string  (allowed  parameters:  any); 

h) 

PLD 

-  partial  line  down; 

i) 

PLU  - 

partial  line  up; 
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j)  SUB  -  substitute  character; 
k)  SP  -  space; 
I)  CR  -  carriage  return; 
m)  LF  -  line  feed; 

n)     -  ccxie  extension  control  functions  (ooo  6.6.4.3). 


6.5.3       Geometric  Graphics  Content 

The  formatted  processable  graphics  content  is  permitted  in  this  DAP  for  use  in  either  the  original  image  or 
in  the  revision  annotation  of  that  image.  Such  geometric  graphics  content  is  encoded  as  CGM  (Computer 
Graphics  Metafile)  metafiles  in  accordance  with  ISO  8632  and  ISO  8613-8.  Each  CGM  figure  must  consist 
of  a  single  picture  only. 

Further  information  concerning  the  specification  of  geometric  graphics  content  information  is  given  in  Annex 
B. 


6.6      Miscellaneous  Features 


6.6.1       Resource  Documents 

A  GenericBlock  may  refer  to  a  corresponding  constituent  in  a  resource  document.  The  GenericBlock  in  the 
resource  document  may  refer  to  content  portions  and  to  presentation  styles  that  are  contained  within  the 
resource  document.  These  are  the  only  constituents  that  may  appear  in  a  resource  document. 


6.6.2       Application  Comments 

Specification  of  the  attribute  Application-comments  is  optional.  When  used  in  conjunction  with  the  Type-of- 
coding  of  Tiled",  it  contains  a  sequence  of  positive  integers,  one  for  each  tile  in  the  content  portion.  The 
sequence  of  integers  is  a  set  of  indices  representing  the  octet  offsets  to  the  beginning  of  the  respective  tiles, 
starting  from  the  beginning  of  the  "content-information".  A  tile  index  of  zero(O)  indicates  that  the  respective 
tile  is  null.  The  integers  will  be  sequenced  in  the  same  order  as  the  tiles.  The  tiles  will  be  sequenced 
primarily  in  the  Pel-path  and  secondarily  in  the  Line-progression  direction  as  defined  by  the  presentation 
attributes. 
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6.7      Document  Management  Features 

Every  document  interchanged  in  accordance  witfi  tliis  DAP  must  include  a  document  profile  containing 
information  which  relates  to  the  document  as  a  whole. 

The  features  specified  by  the  document  profile  are  listed  below.  A  definition  of  the  information  contained 
in  these  features  is  given  in  the  corresponding  attribute  definitions  in  ISO  8613-4. 

Document  constituent  information: 

a)  specific  layout  structure; 

b)  generic  layout  structure; 

c)  presentation  styles  (optional); 

d)  resource  document  information  (optional). 
Document  characteristics: 

a)  document  application  profile; 

b)  document  application  profile  defaults; 

c)  document  architecture  class; 

d)  content  architecture  class; 

e)  interchange  format  class; 

f)  ODA  version  date; 

g)  raster  graphics  content  defaults. 
Non-basic  document  characteristics: 

a)  page  dimensions; 

b)  medium  type; 

c)  raster  graphics  presentation  features. 
Document  management  attributes: 

a)  document  description  (see  note  1); 

b)  dates  and  times; 
I            c)  originators; 
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d)  other  user  information; 

e)  external  references; 

f)  local  file  references; 

g)  content  attributes; 

h)  security  information. 

NOTE  -  The  document  description  includes  the  specification  of  the  document  reference. 
The  attributes  applicable  to  the  document  profile  are  defined  in  table  D.3,  Annex  D. 


7     Specification  of  Constituent  Constraints 


7.1      Document  Profile  Constraints 


7.1.1       Macro  Definitions 

--  General  macros  -- 
DEFINE(FDA,  "{'formatted'}") 

DEFINE(DAC,"DocumentProfile  (Document-architecture-class)") 

DEFINE(FC,"  ASN.1  {2  826  0}")  ~  Character  formatted  ~ 

DEFINE(FPR,"  ASN.1  {2  8  2  7  2}")  -  Raster  graphics  formatted  processable  - 

DEFINE(FPG,"  ASN.1  {2  8  2  8  0}")  ~  Geometric  graphics  formatted  processable  - 

~  Basic  page  dimensions.  - 
DEFINE(BasicPageDimension," 

-fREQ  #horizontal-dimension  {REQ  #fixed-dimension  {  <  -"10800  1.9240  }}, 
REQ  #vertical-dimension  {REQ  #fixed -dimension  {  <  -528001. .12400  }}| 

 Any  gIzo  equal  to  or  omallor  than  the  actual  page  size  of  ISO  A1  and  ANSI  E  portrait. — 

I  {-REQ  #horizontal-dimension  {REQ  #fixed-dimension  {  <  -^62800  1  ..12400  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  <  -10800  1..9240  }}f 

 Any  oizo  equal  to  or  smallor  than  the  actual  page  size  of  ISO  A1  and  ANSI  E  landocapo. — 

") 

-  Any  equal  to  or  smaitef  than  CARA  (Common  Assured  Beproductiort  Area)  of  ISO  A4  and  NA  A.  Both 
Portrait  aand  Landscape  may  be  specified. 

~  Non-basic  page  dimensions.  ~ 
DEFINE(NonBaGioPagoDimonGionG," 

[REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  ['10801..<18000]  ], 
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REQ  #vortioal  dimonoion  [REQ  #fi)(od  dimonoion  [63801. .21 1200)]] 

 Any  oizo  larger  than  tho  rango  of  baoio  valuoo  in  ANSI  E  portrait  and  oqual  to  or  omollor  than  tho  

full  oizo  of  ANSI  K  portrait. — 

I  [REQ  #horigontai  dimonoion  [REQ  #fixod  dimonoion  [62801. .21 1200]], 
REQ  #vortioal  dimonoion  [REQ  #fixod  dimonoion  [40801. . 48000]  ]  ] 

 Any  oizo  larger  than  tho  rango  of  baoio  valuoo  in  ANSI  E  landooapo  and  oqual  to  or  omallor  than  

tho  full  oizo  of  ANSI  K  landocapo. — 

I  [REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  [13200]], 

REQ  #vortioal  dimonoion  [REQ  Vfixod  dimonoion  [>-  16801]]] 

 Any  portrait  oizo  larger  than  tho  typioal  foldout  oizo  (11  in  x  14  in)  including  11  inoh  roll  papor. — 

I  [REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  [>-  16801]], 
REQ  #vortioal  dimonoion  [REQ  #fixod  dimonoion  [13200]]] 

— Any  landooapo  oizo  larger  than  tho  typioal  foldout  oizo  (1 4  in  x  1 1  in)  inoluding  1 1  inoh  roll  papor 

{R£Q  #tiorlzontal<llmension  {REQ  #<ixed-dlmension  {1>39680}}, 
REQ  #v^lbal-cltmeii$lon  {REQ  #flj<ed-dlme«slon  {12401  ..56120})} 
I  iHEQ  #ttorizontaWirnension  {REQ  #1iKed-dlfnension  {9241. 39680}}, 
REO  #vert!o$l-cllmenslort  -{REQ  #fk6cl-<llm6nslon  {1..56120)})- 

up  to  ISO  AD  portrart 
I  {REQ  #liorl2om$i-<)im$ii$ion  {REQ  #t!(6cl-dim$n$ion  {I..aai2()}}, 
REQ  #vertjcaWimensjon  {REQ  #JI>{eclKJImenslor5  {924t„39680}}} 
I  {REQ  #horf2<?rttaMirftenslon  {REQ  #fis<ed-<IJmenslon  {I240i»56i20>|, 
REQ  #v©rtlcalHd:imenslon  {REQ  #^ed-dlmension  {I^SQ^BO}}}- 

-  ijp  to  t$0  AO  landscape  - 

I  {REQ  #liori2onital-dlmension  {REQ  #fixed-cllmenslon  {1«46000>}, 
REQ  #v6rtlcal-<jlmenslon  {REQ  #fk6d-dlmenslort  {I240i.,2ti200}}} 
1  {REQ  #liorJzor»taMlmension  {REQ  #feced-dlmension  {9a4l<.48000}}, 
REQ  #vertloal-dlmenslQn  {REQ  #ftxed-dlmenslQn  {1,.211200)}} 

«-  up  to  ANSI  J/K  ponraft 
I  {REQ  #tiQrl20iital-dlmemldn  {REQ  #fixed-dlmenslQn  {1,.211200|}, 
REQ  #vertlcal^lmenslon  {REQ  #fixed-dtmenslon  {^4UABO00}}} 
I  {REQ  #hori2:of4tal-dimenpsoii  {REQ  #fked-<limen$loii  {12401 .,2 11200)}, 
REQ  #veftjcal-<j»rnensjon  {REQ  #fl>{ed-dlrnBnsion  {1.48000}}} 

-  up  to  ANSIJ/K  landscape  - 

\  {REQ  #horizor»taWlfnensjon  {REQ  #fl>ced'dlrnen8ion  {1*12141  }>, 
REQ  #veftlcal-dlmanslQtt  {REQ  ^ftxed-dlmenslon  { 1 2401 -171 96}} > 
I  {REQ  #riorKontal-dlmension  {REQ  #fi}(ed-dlmension  {9a4l,<t2Hl}}, 
REQ  #v6rtlo$l-<ilmen$lo»  {REQ  #fk6d-dlmen$lort  {1..  17196}}} 

--up  to  Japanese  legal  portrait  - 
[  {REQ  #hor1z0ntal-dlmefislort  {REQ  #fb{ad-<l»m6nsion  {1..17196}}, 
REQ  #vertlcal*dirnen8jon  {REQ  #ftxed-dlmension  {924^42141}}} 
I  {REQ  #hQrl2drital-cllit4anslQn  {REQ  #ftx$d-dlmanslcin  {12401.17196}}, 
REQ  #v©rticalHdlnr«nslon  {REQ  #fixed-dlm€nsion  {t>1214i}}} 

-  ^pto  Japan$s&iagaNand$capa  - 

I  {REQ  #liorKontalHiimensron  {REQ  #«xed-dliT»ensioR  {13200}}, 
REQ  #vertloal'<Jlnien$loii  {REQ  #fi){ecl-dlmanslon {>«  16801} }} 
-  Any  portrait  size  larger  than  ^etypicaf  foldout  size  (11  In  x  14  in)  Including  11  inch  roll  paper,  ^ 
I  {REQ  #tior1zontal-d(menslon  {REQ  #1ked-d [mansion  {>«  168QI}>, 


23 


PART  22  -  ODA  Image  DAP 


June  1992  (Stable) 


Any  lemdscape  size  larger  tJian  the  typical  iDldmit      (14  In  x  1  llr^  including  1 1  inch  rdS  papm  »«- 

i 

DEI?l^iEp?eml^$slblePageDlrneRsl0ntSj^s 

{REQ  #hofIzoRtal-dimen3iorj  {REO  #fi>ced*<J]mension  {1.39680}}, 
REQ  #v6ftlcal-dim6ns!ori  {REQ  #fjx6d-dimenslon  {1.,S612Q}» 

"  up  to  ISO  AD  portraits:** 
I  {REQ  #ho^Orttal-dimenslqr}  {REQ  #fix6d-dlm6tt$lorJ  '{l..S6120}K 
REQ  #v€^ical^men8ion  {REQ  #flxecl^Jrnensior)  {Ix.ddSSO}}} 

->  gptol$OAotandsoape  ~ 
I  {REO  #hc»ieomal*<j4menslon  {REQ  #fixed><jlmeinsiorj  {1.48000}}, 
REQ  #vertlcal-<llmen$loa  {REQ  #<lKed-<limenslofi  {I^ti200}}} 

-  up  to  ANSI  J/K  portrait  « 

I  {REQ  #hor'l2orital-dSm0nslon  {REQ  #fb<ed-d1men$ion  {1.2t1200}}. 
REQ  #veftlcal -dimension  {REQ  #fixed<llmens!on  {1.. 48000}}} 

-  up  to  ANSI  J/K  landscape  - 

I  {REQ  #tionzomaW!mension  {REQ  #fb<ed-dlmension  {1.,12141}}» 
REQ  #v6rtica!-dimension  {REQ  #fixed-dimfinsloii  {1.17196}}} 

-  up  to  Japanese  lagal  poftraltM 

{  {REQ  #hor1zontai-dimfinsion  {REQ  #fLxed-dtm$nslO)i  {1.1 7196} }» 
REQ  #verticaWirnension  {REQ  #fixed-d!rrjension  {1.12141}}} 

-  Up  to  Japanese  1^1  land$capd  - 

i 

DEFINE(NominalPageSizes," 

--  ISO  Page  Sizes  -- 

{■REQ  #horizontal-dimension  {7015},  REQ  #vertical-dimension  {9920} 

--  ISO  A5  Portrait  --  } 
I  iREQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {7015} 

--  ISO  A5  Landscape  --  } 
I  fREQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {14030} 

--  ISO  A4  Portrait  --  } 
I  iREQ  # horizontal-dimension  {14030},  REQ  #vertical-dimension  {9920} 

--  ISO  A4  Landscape  --  } 
I  -{REQ  #horizontal-dimension  {14030},  REQ  #vertical-dimension  {19843Q} 

--  ISO.  A3  Portrait  -- }- 
I  -fREQ  #horizontal-dimension  {19843iO},  REQ  #vertical-dimension  {14030} 

--  ISO  A3  Landscape  --  } 
I  -fREQ  #horizontal-dimension  {198430},  REQ  #vertical-dimension  {280630} 

--  ISO  A2  Portrait  --  } 
I  iREQ  #horizontal-dimension  {280630},  REQ  #vertical-dimension  {19843i|} 

--  ISO  A2  Landscape  --  } 
I  {-REQ  #horizontal-dimension  {280630},  REQ  #vertical-dimension  {397326i|} 

--  ISO  A1  Portrait  --  } 
I  -fREQ  #horizontal-dimension  {39732680},  REQ  #vertical-dimension  {28063i|} 

-  ISO  A1  Landscape  --  } 

I  -fREQ  #horizontal-dimension  {39732680},  REQ  #vertical-dimension  {56473t2p} 
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--  ISO  AO  Portrait  --  ]■ 
I  -fREQ  #hori2ontal-dimension  {56+73120},  REQ  #vertical-dimension  {39732680} 

-  ISO  AO  Landscape  -- 1 

--  ANSI  Page  Sizes  -- 

I  -f-REQ  #horizontal-dimension  {10200},  REQ  #vertical-dimension  {13200} 

--  ANSI  A  Portrait  --  ]■ 
I  -f-REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {10200} 

--  ANSI  A  Landscape  --  } 
I  -fREQ  #horizontal-dimension  {10200},  REQ  #vertical-dimenslon  {16800} 

--  ANSI  Legal  Portrait  -- 1 
I  -f-REQ  #horizontal-dimension  {16800},  REQ  #vertlcal-dimenslon  {10200} 

ANSI  Legal  Landscape  -- 1 
I  -{-REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {20400} 

--  ANSI  B  Portrait  --  ]■ 
I  -{-REQ  #horizontal-dimension  {20400},  REQ  #vertical-dimension  {13200} 

--  ANSI  B  Landscape  --  f 
I  -{-REQ  #horizontai-dimension  {20400},  REQ  #vertical-dinnension  {26400} 

--  ANSI  C  Portrait  --  ]■ 
I  -fREQ  #horlzontai-dimenslon  {26400},  REQ  #vertical-dimension  {20400} 

--  ANSI  0  Landscape  -- 1 
I  {REQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension  {40800} 

--  ANSI  D  Portrait  -  ]■ 
I  -fREQ  #horizontal-dimension  {40800},  REQ  # vertical-dimension  {26400} 

--  ANSI  D  Landscape  --  ]■ 
I  -{-REQ  #horizontal-dinnension  {40800},  REQ  #vertical-dimension  {52800} 

-  ANSI  E  Portrait  -  ]■ 

I  -f-REQ  #horizontal-dimension  {52800},  REQ  #vertical-dimension  {40800} 

--  ANSI  E  Landscape  ~  } 
I  -f-REQ  #horizontal-dimension  {33600},  REQ  #verticalHdimension  {48000} 

--  ANSI  F  Portrait  ~  ]■ 
I  -f-REQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {33600} 

-  ANSI  F  Landscape  -- 1 

I  -f-REQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {108000} 

--  ANSI  G  Portrait  -  ]■ 
I  -fREQ  #horizontal-dimension  {108000},  REQ  #vertical-dimension  {13200} 

--  ANSI  G  Landscape  --  f 
i  -f-REQ  #horizontal-dimension  {33600},  REQ  #vertical-dimension  {171600} 

-  ANSI  H  Portrait  ~  | 

I  -f-REQ  #horizontal-dimension  {171600},  REQ  #vertical-dimension  {33600} 

--  ANSI  H  Landscape  --  f 
I  -f-REQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {211200} 

~  ANSI  J  Portrait  -  } 
I  -f-REQ  #horizontal-dimension  {211200},  REQ  #vertical-dlmension  {40800} 

--  ANSI  J  Landscape  ~  ]■ 
I  -fREQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {171600} 

--  ANSI  K  Portrait  -  ]■ 
I  -fREQ  #horizontal-dimension  {171600},  REQ  #vertical-dimension  {48000} 
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-  Foldouts  - 


I  -fREQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {16800} 

--  Foldout  Portrait  --  f 
I  -fREQ  #horizontal-dimension  {16800},  REQ  #vertical-dimension  {13200} 

--  Foldout  Landscape  --  ]■ 
I  -{REQ  #horizontal-dimenslon  {13200},  REQ  #vertical-dlmension  {>=  16801} 
--  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  In)  including  11  inch  roll  paper  - 
I  -fREQ  #horizontal-dimension  {>=  16801},  REQ  #vertical-dimension  {13200} 
--  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  11  in)  including  11  inch  roll  paper  - 


--  Macro  defining  permissible  code  extension  announcers  -- 

DEFINE(CDEXTEN,  "  ESC  02/00  05/00.  LSO 
[ESC  02/00  05/03],       --  LSRI  - 
[ESC  02/00  05/05],       --  LSR2  -- 
[ESC  02/00  05/07],      --  LSR3  -- 
[ESC  02/00  05/1 0] ,         SS2  -- 
[ESC  02/00  05/11]  --SS3-- 


--  Macro  defining  permitted  graphic  renditions 

DEFINE(GRAPHICRENDIT10NS  " 

{'cancel'  |  'increased -intensity' 
I  'italicised'  |  'underlined'  |  'crossed-out' 
I  'primary-font'  |  'first-alternative-font' 
I  'second-alternative-font'  |  'third-alternative-font' 
1  'fourth-alternative-font'  |  'fifth-alternative-font' 
I  'sixth-alternative-font'  |  'seventh-alternative-font' 
I  'eighth-alternative-font'  |  'ninth-alternative-font' 
I  'doubly-underlined'  |  'normal-intensity' 
I  'not-italicised'  |  'not-underlined'  |  'not-crossed-out'}... 


~  Macros  defining  final  character  for  designation  ~ 

DEFINE(FCORE,  "04/02  -  the  94  characters  of  the  IRV  of  ISO  646 
(revised  1990)  (i.e..  ASCII)  ~") 

DEFINE(F646,   "~  a  final  character  designating  any  version  of  ISO  646 
except  04/02  ~") 

DEFINE(F94S.   "-  a  final  character  designating  any  registered  94  single 
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byte  graphic  character  set  --") 

DEFINE(F94M,       a  final  character  designating  any  registered  94  multi 
byte  graphic  character  set  -") 

DEFINE(F96S,   "-  a  final  character  designating  any  registered  96  single 
byte  graphic  character  set  --") 

DEFINE(F96M,       a  final  character  designating  any  registered  96  multi 
byte  graphic  character  set  --") 

DEFINE(FEMPTY,  "07/14  --  the  empty  set  --") 

-  Macros  defining  designation  sequences  -- 

DEFINE(DEG-CORE-GO.  "ESC  02/08  $FCORE") 

--  Designate  the  94  characters  of  the  IRV  of 
ISO  646  to  GO  -- 

DEFINE(DEG-646-GO,    "ESC  02/08  $F646") 

--  Designate  any  version  of  ISO  646,  except  04/02, 
to  GO  -- 

DEFINE(DEG-ANY-G1 ,    "{ESC  02/09  $F94S 
I  ESC  02/04  02/09  $F94M 
I  ESC  02/13  $F96S 
lESC  02/04  02/13  $F96M}") 

-  Designate  any  character  set  to  G1  - 

DEFINE(DEG-ANY-G2,    "{ESC  02/10  $F94S 
I  ESC  02/04  02/10  $F94M 
I  ESC  02/14  $F96S 
I  ESC  02/04  02/14  $F96M}") 

-  Designate  any  character  set  to  G2  -- 

DEFINE(DEG-ANY-G3.    "{ESC  02/11  $F94S 
I  ESC  02/04  02/1 1  $F94M 
I  ESC  02/15  $F96S 
I  ESC  02/04  02/15  $F96M}") 
--  Designate  any  character  set  to  G3  - 

DEFINE(DEG-EMPTY-G1,  "ESC  02/09  $FEMPTY") 
--  Designate  the  empty  set  to  Gl  - 

-  Macros  defining  shift  functions 

DEFINE(LSO,    "00/15")        -  locking  shift  invoking  GO  to  GL - 
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DEFINE(LS1R,    "ESC  07/14")    --  locking  shift  invoking  G1  to  GR  - 
DEFINE(LS2R.    "ESC  07/13")    --  locking  shift  invoking  G2  to  GR  - 
DEF:NE(LS3R.    "ESC  07/14")    -- locking  shift  invoking  G3  to  GR - 
DEF1NE(.SS2.     "08/14")        -  single  shift  invoking  G2  to  GL -- 
DEFINE(SS3,     "08/15")  single  shift  invoking  G3  to  GL - 

-  Macro  defining  permissible  graphic  character  sets.  - 

DEFINE(PERMIT-GRCHAR,  "  {$DEG-CORE-GO  $LSO 
|$DEG-646-G0  $LSO}, 
{$DEG-ANY-G1  $LS1R 

|$DEG-ANY-G2  $LS2R 

|$DEG-ANY-G3  $LS3R}... 
|{$DEG-EMPTY-G1  $LS1R}  ") 

--  Macro  defining  default  graphic  character  sets  -- 

DEFINE(DAP-DEFAULT-GRCHAR,  "$PERMIT-GRCHAR") 

--  Macro  defining  basic  character  sets.  Note  that  this  nnacro  is  defined 
for  clarification  of  the  specification  and  is  not  to  be  used  in  any 
other  part  of  this  DAP  specification.  - 

DEF!NE(BASIC-GRCHAR,  "  $DEG-CORE-G0  $LSO, 
$DEG-EMPTY-G1  $LS1R  ") 


--  Macro  defining  non-basic  character  sets  -- 

DEF1NE(N0N-BASIC-GRCHAR,  "  {$DEG-646-G0 
|$DEG-ANY-G1 
I  $DEG-ANY-G2 
|$DEG-ANY-G3}...  ") 


--  Macro  defining  character  sets  used  in  document  profile  attributes 

DEFINE(PROFCHAR,  "  {$DEG-CORE-G0  $LS0, 
|$DEG-646-G0  $LSO}, 
{$DEG-ANY-G1  $LS1R 
|$DEG-ANY-G2  $LS2R 
|$DEG-ANY-G3  $LS3R 
|$DEG-EMPTY-G1  $LS1R}  ") 
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--  Macro  defining  comments  character  sets  -- 

DEFINE(COMCHAR,  "  {ESC  02/00  05/00,         --  LSO  -- 
[ESC  02/00  05/03],        --  LSRI  - 
[ESC  02/00  05/05],        --  LSR2  - 
[ESC  02/00  05/07],        -  LSR3  - 
[ESC  02/00  05/10],       -  SS2  - 
[ESC  02/00  05/11]},  --SS3- 

{$DEG-CORE-G0  [LSO] 
|$DEG-646-G0  [LSO]}, 

{{$DEG-ANY-G1  [$LS1R] 
|$DEG-ANY-G2  [$LS2R] 
|$DEG-ANY-G3  [$LS3R]}... 
|$DEG-EMPTY-G1  $LS1R}}  ") 


-  Macro  defining  cfiaracter  sets  used  for  alternative  representation  -- 
DEFINE(ALTCHAR,  "$PROFCHAR") 


7.1.2 


Constituent  Constraints 


7.1.2.1  DocumentProfile 

{ 

-  Presence  of  document  constituents  -- 


REQ  Specific-layout-structure 

PERM  Generic-layout-structure 

PERM  Presentation-styles 

PERM  Resource-document 

PERM  Resources 


{'present'}, 
{'factor-set'}, 
{'present'}, 
{ANYVALUE}, 
{MUL  {REQ  #resource-identifier  {ANY_VALUE}, 

REQ  #resource-object-class-identifier  {ANY  VALUE}}}, 


-  Document  characteristics  ~ 

REQ  Document-application-profile 

REQ  Document-application-profile-defaults 

~  Document  architecture  defaults  - 

REQ  #content-architecture-class 
PERM  #dimensions 


{--  See  clause  8  for  a  definition  of  the  permitted  values  for 
this  attribute.  --}, 


{ 


{$FPR}, 

{$BaGicPagoDimonsions 
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PERM  #medium-type 

PERM  #nominal-page-size 
PERM  #side-of-sheet 


$NonBaoioPagoDimonoiona$P0mi}$sifc4^a0eDiffl$ni^k>n$}. 
{ 

{$NominalPageSizes}, 
{ANY_VALUE}}, 


--  Any  permitted  medium  type.  Both  landscape  and  portrait  may  be  specified.  - 

REQ     #type-of-coding  {ASN.1  {2  83  70}--  T6  encoding  ~ 

I  ASN.1  {2  8  3  7  5}  -  tiled  encoding  ~  }, 
PERM    #page-posltion  {ANY_VALUE}, 
PERM   raster-graphics-contents-defaults  { 

PERM  #pel-path  {ANY_VALUE}, 
PERM  #line-progression  {ANY_VALUE}. 
PERM  #pel-spacing  {REQ  #length  {6-h4ANY  VALUE}, 

REQ  #pel-spaces  {4ANYJ^ALUE}}, 

PERM  #spacing-ratio 

{REQ  #line-spacing-value  {ANY_VALUE}, 
REQ  #pel-spacing-value  {ANY_VALUE}}, 
PERM   #compression  {'comprosGod'  |  'unoomprooood'ANY^VALUfE}, 

PERM  #clipping  {ANY_VALUE}}, 
PERM   #geometric-graphics-content-defaults  {ANY_VALUE}, 
PERM    #character-content-defaults  { 

PERM  #alignment  {ANY_VALUE}, 
PERM  #character-spacing  {ANY_VALUE}, 
PERM  #character-fonts  {ANY_VALUE}. 
PERM  #character-orientation  {'0-degrees'  |  '90-degrees'}, 
PERM  #character-path  {'0-degrees'     |     '90-degrees'     |  '180-degrees' 

'270-degrees'}, 

PERM  #code-extension-announcers  { $CD E)CTANCD£XTEN} , 
PERM  #graphic-character-sets  {$PERMIT-GRCHAR}, 

PERM  #graphic-character-subrepertoire  {$GRAPHICRENDITIOMSANY  VALUE}, 
PERM  #graphic-rendition  {$GRAPHICRENDITIONS}, 
PERM  #line-progression        {'90-degrees'  |  '270-degrees'}, 
PERM  #line-spacing  {ANY_VALUE}, 
PERM  #line-layout-table         {ANY  VALUE}}, 

~  End  of  document  architecture  defaults  ~ 


REQ  Document-architecture-class 
REQ  Content-architecture-classes 
REQ  Interchange-format-class 


REQ  ODA-version 


{$FDA}, 

{[$FPR],  [$FPG],  [$FC]{$FPa  \  $FPa  |  $FC}.«}. 
{--  This  attribute  reqLilr0<l  only  for  ODIF  lttt«<jrian0$.  See 
clause  8  for  a  definition  of  the  permitted  values  ifor  this 
attribute.  --}, 


{REQ  #standard-or-recommendation    {'ISO  8613'}, 

REQ  #publication-date  {'1080  07  0119gM2-31:'}}. 

-  This  date  represents  the  date  that  this  DAP  was  approved.  This  « ttie  only 
apfitfoved  value,  however,  the  <iat6  will  be  changed  If  the  DAP  1$  ^nlBcantty 
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~  revised  tf  the  date  1$  f6v!$ed,  use  of  the  new  date  Is  r0(^&dW^WnWW 
«-  addlBonal  ftjnctionahty  is  being  used.  That  is,  legacy  products  may  continue  to 

||||||||j|||ipf  ifer:  DAPf  '  ■ ' ' 

-  Non-basic  document  characteristics  - 


PERM 
PERM 
PERM 
PERM 
PERM 


PERM 


Profile-character-sets  {  $PROFCH  AR  } . 

Comments-character-sets  {$COMCHAR  } , 

Alternatlve-representatlon-character-sets  {$ALTCHAR}, 

Page-dimensions  {PMUL  {$NonBasicPageDimensions}}, 

Medium-types  {PMUL{ 

PERM   #nominal-page-slze  {$NominalPageSizes}, 

PERM    #side-of-sheet  {ANY_VALUE}}}, 

All  v^uea  <^  "medium  type"  are  non-basfc  ^ 
Cocitag-a.ttfit)yte$  { 
filEO  #raslBr-Qraphics-cod)ng-attributes  { 


fiEQ  #oompre$$loa 
Presentation-features 
PERM 


{'ur«Jompfes$6d*}}}, 


{ 


#character-presentation-features 
I  PERM  #character-orientation 
PMUtj  FEftM  #character-path 


PmM 


{ 


1  80-degrees', 


{'90<legrees'}7 

{ '90-degrees', 
'270-clegrees'}T 

l>EBM  #graphic-character-sets  {ANYJ^LlIf  IpXCEPT  pBASIC-GRCHARh 
f?EBM  #graphic-character-subrepertoire  {ANY_VALUEfd}7 
PMULj  PERM  #line-spacing  {ANY  VAUJE}  EXCEPT  |150,200,300,400}7 

I  PERM  #line-progression  {'90-degrees'}}}? 
PERM  #Raster-graphics-presentation-features    {  MUL  { 
PMUtj  PERM  #pel-path        {'1 80-degrees'  j 

'270-degrees'}T 
#line-progression        { '90-degrees' }t 


I  PERM 


#pel-spacing    {REQ    #length    {ANY_VALUE}    EXCEPT  &t 
REQ  #pel-spaces  {ANY^VALUE)  EXCEPT  |1}}t 


PMULj  PERM  #spacing-ratio 

{REQ  #line-spacing-value        |ANY_VAI_UE)  EXCEPT  {1}, 
REQ  #pel-spacing-value  |ANY  VALUE}  EXCEPT  {1 }}}}!, 


~  End  of  Non-basic  characteristics  - 
~  Additional  document  characteristics  ~ 

PERM  Fonts-list         {PMUL  {REQ  #font-identifier  {ANY  VALUE}, 

REQ  #font-reference  {ANY_VALUE}}}, 
~  The  format  of  the  parameter  "font-reference"  is  defined  in  annex  B  ~ 


~  Document  management  attributes  ~ 
~  Document  description  ~ 
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PERM  Title 

PERM  Subject 

PERM  Document-type 

PERM  Abstract 

PERM  Keywords 

REQ  Document-reference 

-  Dates  and  times  ~ 

PERM  Document-date-and-time 

PERM  Creation-date-and-time 

PERM  Local-filing-date-and-time 

PERM  Expiry-date-and-time 

PERM  Start-date-and-time 

PERM  Purge-date-and-time 

PERM  Release-date-and-time 

PERM  Revision-history 

-Originators  ~ 

PERM  Organizations 

PERM  Preparers 

PERM  Owners 

PERM  Authors 

--  Other  user  information 

PERM  Copyright 

PERM  Status 

PERM  User-specific-codes 

PERM  Distribution-list 

PERM  Additional-information 


{ANYSTRING}, 

{ANYSTRING}. 

{ANY_STRING}, 

{ANY_STRING}, 

{ANY_VALUE}. 

{ANY_VALUE}, 


{ANYSTRING}, 
{ANY_STRING}, 
{ANY_STRING}, 
{ANY_STRING}, 
{ANYSTRING}, 
{ANY_STRING}, 
{ANY_STRING}, 
{ANY  VALUE}, 


{ANY_STRING}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{ANY  VALUE}, 


{ANY_VALUE}, 
{ANY_STRING}, 
{ANYSTRING}, 
{ANY_VALUE}. 
{ANY  VALUE}, 


~  External  references  ~ 
PERM  References-to-other-documents 
PERM  Superseded-documents 


{ANYVALUE}, 
{ANY  VALUE}, 


PERM 


-  Local  file  references  ~ 
Local-file-references 


{ANY  VALUE}, 


~  Content  attributes  - 
PERM  Document-size 
PERM  Number-of-pages 
PERM  Languages 

~  Security  information 
PERM  Authorization 
PERM  Security-classification 
PERM  Access-rights 


{ANYJNTEGEfiVALUE}, 
{ANYJNTEGER}, 
{ANY  STRING}, 


{ANY_VALUE}, 

{ANY_STRING}. 

{ANY_STRING} 


} 
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7.3      Layout  Constituent  Constraints 


7.3.1       Macro  Definitions 


DEFINE(CHAR,"  CONTENT_ID_OF(GHARAGTE«Character«content*portion)") 
DEFINE(RAST,"  CONTENT_ID_OF(RASTERaa5ter-gmphlc«-content-portion)") 
DEFINE(GEOM,"  CONTENTJD_OF(GEOMETRIGGeometrtc-graphic$-CQntent-portk)n)") 


7.3.2       Factor  Constraints 

FACTOR:  ANY-LAYOUT  { 

SPECIFIC: 

PERM  Object-type 

REQ  Object-identifier 

PERM  Subordinates 

PERM  User-visible-name 

PERM  User-readable-comments 
} 


{VIRTUAL}, 

{ANYVALUE}, 

{VIRTUAL}, 

{ANY_VALUE}, 

{ANYVALUE}, 


7.3.3       Constituent  Constraints 


7.3.3.1  Documentl^youtRoot 

DocumentLayoutRoot:  ANY-LAYOUT  { 

SPECIFIC: 

REQ  Object-type 

REQ  Subordinates 

} 


{  'document-layout-root'}, 
{SUB_ID_OF(CompositePage)  +  } 


7.3.3.2  ComposltePage 

CompositePage:  ANY-LAYOUT  { 

SPECIFIC: 
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REQ 
REQ 


PERM 
PERM 

PERM 
PERM 
} 


Object-type 
Subordinates 


PERM  Dimensions 


Page-position 
Medium-type 

Imaging-order 
Application-comments 


{'oompooito  page'}, 
{SUBJD_OF(Originallmage), 
[SUBJD_OF(RevisionAnnotation)  +  ]}, 
{REQ  #horizontal  dimonoion 

(REQ  #fixod  dimonoion  [$BaoioPagoDimonoionG 

I  SNonBaoioPagoDimonsionG)  j , 
REQ  #vortioal  dimonoion 

[REQ  #fixod  dimonoion  ($BaoioPagoDimonGiono 

+ 

$NonBaGioPagoDimonoiono]  ]  $Pe^rmlssiblePage 
Dimensi<;»i$}, 
{ANY_VALUE}, 

{REQ  #nominal-page-size  {$NominalPageSizes}, 
REQ  #side-of-slieet  {ANY_VALUE}}, 
{ANYVALUE}, 
{ANY  VALUE} 


7.3.3.3 


Originallmage 


Originallmage: 

SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Position 


PERM  Dimensions 


PERM  Application-comments 
} 


ANY-LAYOUT  { 


{'frame'}. 

{SUBJD_OF(SpecificBlocl<)  +  }, 
{REQ  #fixed-position 

{REQ#horizontal-position{ANY_INTEGERVALU£}, 

REQ  #vertical-position  {ANY_lNffiGBRVAIiJE}}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension{ANYJNTEGERVALUE}}, 
REQ  #  vertical -dimension 

{REQ  #fixed-dimension{ANYJ^ffEGER\/ALUE}}}, 
{ANY  VALUE} 


7.3.3.4  RevisionAnnotation 

RevisionAnnotation:  ANY-LAYOUT  { 


SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Position 


PERM  Dimensions 


{'frame'}, 

{SUB_ID_OF(SpecificBlock)}, 

{REQ  #fixed-position 

{  REQ#horizontal-posltion  {  ANY_INTEGERVALUe}, 
REQ  #vertical-position  {ANY_M^GS?VALIJE}}}, 

{REQ  #horizontal-dimension 

{REQ  #fixed-dimension{ANY_tt4TeGERVALUE}}, 
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PERM  Application-comments 


REQ  #vertlcal -dimension 

{REQ  #fixed-dimension{ANYJNTEGE«VAlJUE}}}. 
{ANYVALUE}} 


7.3.3.5 


SpecificBlock: 


SpecificBlock 


{ 


SPECIFIC: 
REQ  Object-type 
REQ  Object-identifier 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


PERM  Object-class 

PERM  Content-architecture-class 

PERM  Transparency 

PERM  Colour 

PERM  User-readable-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 


PERM 


~  PStylel  for  character 
Presentation-attributes 


{'block"}, 

{ANYVALUE}. 

{$CHAR  I  $RAST  |  $GEOM}. 

{REQ  #fixed-position  { 

REQ  #horizontal-posltion  {ANYJNTEGERVALOE}; 

REQ  #verticai-position  {fim_mEGBf^MMB}}}, 
{REQ  #horizontal-dimension 

{REQ  #fixed-dimension{ANYJNTeG6RVALUE}}, 
REQ  #vertical-dimension 

{REQ  #fixed-dimension{ANY_INFEGERVAlJUE}}}, 
{ANY_VALUEOBJECT_CLA$$  ID  OP{OenericBlocl<)}, 
{$FC  I  $FPR  I  $FPG}, 
{'transparent'  |  'opaque'}, 
{'colourless'  |  'white'}, 
{ANY_STRING}, 
{ANY_STRING} 
{ANYVALUE}, 
~  See  8.1.3  and  8.2.3  ~ 

{STYLEJD_0F(PStyle1)    |    STYLEJD_0F(PStyle2)  | 
STYLEJD_0F(PStyle3}, 
content,  PStyle2  for  geometric,  &  PStyleS  for  raster  - 
{ 


CASE  SpecificBlock(Content-portions|  OF  { 


|$CHAR|: 


#character-attributes  { 
PERM  #alignment  {ANY_VALUE}, 
PERM  #character-spacing  {ANY_VALUE}, 
PERM  #character-fonts  {ANY_VALUE}. 
PERM  #character-orientation  {'0-degrees'  |  '90-degrees'}, 
PERM  #character-path  {'0-degrees'     |  '90-degrees' 

'270-degrees'}, 

PERM  #code-extension-announcers  {$CDEXTANCD£X|||i}, 
PERM  #graphic-character-sets  {$PERMIT-GRCHAR}, 
PERM  #graphic-character-subrepertoire  {ANY_VALUE}, 
PERM  #graphic-rendition  {$GRAPHICRENDITIONS}. 
PERM  #line-progression        {'90-degrees'  |  '270Hdegrees'}, 
PERM  #line-spacing  {ANY_VALUE}, 


'180-degrees' 


35 


PART  22  -  ODA  Image  DAP 

PERM  #line-layout-table 


June  1992  (Stable) 


{ANY_VALUE}, 


|$RAST|: 


#  raster-graphics-attributes 
PERM  #Pel-path 
PERM  #Line-progression 
PERM  #Pel-spacing 
PERM  #Spacing-ratio 

PERM  #Clipping 


{ 

{ANY_VALUE}, 
{ANY_VALUE}. 
{ANY_VALUE}, 

{REQ  #line-spacing-value  {ANY_VALUE}, 
REQ  #pel-spacing-value  {ANY_VALUE}}, 
{ANY  VALUE}}:|7 


|$GEOM|: 

|PERM  #geometric-graplnics-attributes  { 

PERM  #picture-dimenslons  {ANY_VALUE}, 
PERM  #picture-orlentation 
PERM  #text-rendition 


{ANY_VALUE}, 

{PERM  #fonts-list  {ANY  VALUE}, 
PERM  #character-set-lists  {ANY_VALUE}}} 


7.3.3.6 


GenericBlock 


GenericBlocl<T 


GENERIC: 
REQ  Object-type 
REQ  Content-portions 
PERM  Position 


PERM  Dimensions 


REQ  Object-class-identifier 

PERM  Resource 

PERM  Content-architecture-class 

PERM  Transparency 

PERM  Colour 

PERM  User-readabie-comments 

PERM  User-visible-name 

PERM  Application-comments 

PERM  Presentation-style 

~  PStylel  for  character 

PERM  Presentation-attributes 


{'block'}, 

{$CHAR  I  $RAST  |  $GEOM}, 
{REQ  #fixed-position  { 

REQ  #horizontal-posltion  {ANYJNTEGERVAUJE} 

REQ  #vertical-position  {ANYJNFEGBW'AUJE}}}, 
{REQ  #  horizontal -dimension 

{REQ  #fixed-dimension{ANY_lNTEGERVALUE}}, 
REQ  # vertical-dimension 

{REQ  #fixedHdimension{ANYJN;EGERVALUE}}}, 

{ANY_VALUE}, 
{ANY_VALUE}, 
{$FC  I  $FPR  I  $FPG}, 
{'transparent'  |  'opaque'}, 
{'colourless'  |  'white'}, 
{ANY_STRING}, 
{ANY-STRING} 
{ANY_VALUE}, 
~  See  8.2  - 

{STYLEJD_0F(PStyle1)    |    STYLE_ID_0F(PStyle2)  | 
STYLE_ID_0F(PStyle3}, 
content,  PStyle2  for  geometric,  &  PStyleS  for  raster 
{ 
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CASE  Oen«irtO©OOk(Content-portions)i  OF  { 


pCHAR|: 

|PERM 


#character-attributes 
PERM  #alignment 
PERM  #character-spacing 
PERM  #character-fonts 
PERM  #character-orientation 
PERM  #character-path 


{ 


PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


{ANY_VALUE}, 
{ANYVALUE}. 
{ANYVALUE}, 
{'0-degrees'  |  '90-degrees'}, 
{'O-degrees'     |  '90-degrees' 
'270-degrees'}, 
#code-extension-announcers  {$CDEXTANC;P£XT||i|}, 
#graphic-character-sets  {$PERMIT-GRCHAR}, 

#graphic-character-subrepertoire  {$GRAPHICRENDITIONSAMY  VAUje}, 


'180-degrees'  | 


#graphic-rendition 
#line-progression 
#line-spacing 
#line-layout-table 


{$GRAPHICRENDITIONS}. 
{'90-degrees'  |  '270-degrees'}, 
{ANY_VALUE}, 
{ANY_VALUE}. 


|$RAST|: 


#raster-graphics-attributes 
PERM  #Pel-path 
PERM  #Line-progression 
PERM  #Pel-spacing 
PERM  #Spacing-ratio 

PERM  #Clipping 


{ 

{ANY_VALUE}. 
{ANY_VALUE}, 
{ANY_VALUE}. 

{REQ  #line-spacing-value  {ANY_VALUE}, 
REQ  #pel-spacing-value  {ANY_VALUE}}7 
{ANY_VALUE}}|7 


pGEOM|: 

|PERM  #geometric-graphics-attributes  { 

PERM  #picture-dimensions  {ANY_VALUE}, 
PERM  #picture-orientation  {ANY_VALUE}, 
PERM  #text-rendition  {PERM  #fonts-list  {ANY_VALUE}, 

PERM  #character-set-lists  {ANY_VALUE}}} 


7.4      Layout  Style  Constraints 

No  layout  style  constraints  applicable  in  this  clause. 
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7.5.1       Macro  Definitions 

No  macro  definitions  are  applicable  to  this  clause. 


7.5.2       Factor  Constraints 

FACTOR:  ANY-PRESENTATION-STYLE  { 


REQ  Presentation-style-identifier 

PERM  User-readable-comments 

PERM  User-visible-name 
} 


{ANY_VALUE}, 
{ANY_STRING}, 
{ANY  STRING}, 


7.5.3       Presentation  Style  Constituent  Constraint 


7.5.3.1 

PStylel : 

PERM 


PStylel 

ANY-PRESENTATION-STYLE  { 
This  style  is  used  for  character  content  ~ 


Presentation-attributes 
PERM  #character-attributes 
PERM  #alignment 
PERM  #character-spacing 
PERM  #character-fonts 
PERM  #character-orientation 
PERM  #character-path 


{ANYVALUE}, 
{ANY_VALUE}, 
{ANY_VALUE}, 
{'0-degrees'  |  '90-degrees'}, 
{'0-degrees'     |  '90-degrees' 
'270-degrees'}, 

PERM  #code-extension-announcers  {$CDE)CrANCD£XTEN}, 
PERM  #graphic-character-sets  {$PERMIT-GRCHAR}, 

PERM  #graphic-character-subrepertoire  {$GRAPHICRENDITIONSMiiMi}, 


'180-degrees'  | 


PERM  #graphic-rendition 

PERM  #line-progression 

PERM  #line-spacing 

PERM  #line-layout-table 


{$GRAPHICRENDITIONS}, 
{'90-degrees'  |  '270-degrees'}, 
{ANYVALUE}, 
{ANY  VALUE}}} 
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PStyle2:  ANY-PRESENTATION-STYLE  { 

-  This  style  is  used  for  geometric  graphics  content  - 

PERM  Presentation-attributes  { 

PERM  #geometric-graphics-attributes  { 

PERM  #picture-dimensions  {ANY  VALUE}, 

PERM  #picture-orientation  {ANY  VALUE}, 

PERM  #text-rendition  {PERM  #fonts-iist{ANY_VALUE}, 

PERM  #character-set-list{ ANY  VALUE} }  }  } 

} 


7.5.3.3  PStyleS 

PStyle3:  ANY-PRESENTATION-STYLE  { 

~  This  style  is  used  for  raster  graphics  content  ~ 


PERM  Presentation-attributes  { 
PERM  #raster-graphics-attributes 
PERM  #pel-path 
PERM  #line-progression 
PERM  #pel-spacing 


PERM  #clipping 

} 


7.6 


7.6.1       Macro  Definitions 

DEFINECTILED,"  ASN.1  {2  8  3  7  5}") 


{ 

{ANYVALUE}, 
{ANYVALUE}, 
{REQ  #length  {ANY  VALUE}, 
REQ  #pel-spaces  {ANY  VALUE}}, 
#line-spacing-value  {ANY  VALUE}, 
REQ  #pel-spacing-value  {ANY  VALUE}}, 
{ANY_VALUE}}} 


-  Tiled  raster  encoding  - 


PERM  #spacing-ratio  {REQ 


Content  Portion  Constraints 


7.6.2       Factor  Constraints 

No  factor  constraints  are  applicable  to  this  clause. 
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7.6.3.1         Character  Content  Portion 

C^act6r-c<jit«rjt*portlor»  { 

REQ  Content-identifier-layout  {CONTENTJD_OF(CNARACTER)iiiiiiiii}, 
PERM  Type-of-coding  {ASN.1{2  8  G  6  0}}, 

PERM  Alternative-representation  {ANY_STRING}, 
PERM  Content-information 

{CHARACTER.  {#STAB  {ANY  VALUE} 

|#SHS  {0^hS^ANy_VAUJE} 

|#SGR  {$GRAPHICRENDITIONS} 

|#SVS  {G^!-a-*ANY_VALUE} 

I  #SLS  {ANY_VALUE} 

I  #SCS  {ANY_VALUE} 

I  #SRS  {ANY_VALUE} 

|#CR 

|#LF 

I  #PLD 

|#PLU 

I  #SP 

|#SUB 

] #$LSO 

I  #$LS1  R 

I  #$LS2R 

I  #$LS3R 

I #$SS2 

|#$SS3 

I  #$DEG-CORE-G0 
I  #$DEG-646-G0 
I  #$DEG-ANY-G1 
I  #$DEG-ANY-G2 
I  #$DEG-ANY-G3 
I  #$DEG-EMPTY-G1 
}••■} 


7.6.3.2 


Raster  Graphics  Content  Portion 


Raster-praphics-corTtent-portion  { 

REQ  Content-identifier-layout 
PERM  Type-of-coding 


PERM  Coding-attributes 


ASN.1{2  8 

3  7  0} 

T.6  encodiifig  - 

ASN.H2  8 

371} 

-  7a  one  dimensional  - 

ASN.1{2 

W" 

-  TA  two  dimen^on^ 

ASN.I{2 
ASHJ{2 

8 
6 

3  ' 
3 

7  3}  ' 

-  bltniap  encoding 

-  iiled  encoding 
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PERM  GsJ^compression  " " {ANY_VALUE}. 

ReQPEFlM       Ni«umber-of-lines  {>0}, 

REQ    Wi|umber-of-pels-per-line  {>0}, 

PERM  Typo  of  ooding  [ASN.1  [0  83  70]  T.6  onooding 

|ASN.1  [3  83  7  3]  bitmap  onooding 

I  ASN.1[a  83  76] — tiled  onooding    ] , 

CASE  Raster-graphics-content-portion  (Type-of-coding)  OF  { 


|$TiLE[>|:       |PERM  l4#jiumber-of-peis-per-tile-line 
PERM  Ni|umber-of-lines-per-tlle 
PERM  Tiliiing-offset 
PERM  Tiille-types 


PERM  Aiternative-representation 
PERM  Content-information 

} 


{ANYSTRING}, 
{RASTER} 


{512}. 
{512}, 

{ANY_VALUE}, 
{'null  background'  | 
'null  foreground'  | 
'T.6  encoded'  | 
'bitmap  encoded'}}}^, 


7.6.3.3        Geometric  Graphics  Content  Portion 


Oeom^c-graphics-content-portion  { 

REQ  Content-identifier-layout 

PERM  Type-of-coding 

PERM  Alternative-representation 

PERM  Content-information 

} 


{CONTENTJD_OF(GEOMETRIC)AHY_VALUE}, 

{ASN.1{2  83  8  0}}, 

{ANY_VALUE}, 

{GEOMETRIC} 


7.7      Additional  Usage  Constraints 

No  other  usage  constraints  are  currently  defined. 
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8     Interchange  Format 

Two  interchange  formats  are  supported  by  this  profile.  The  Interchange  Format  Class  A  can  be  used  by 
applications  requiring  a  binary  encoding  based  on  ASN.1.  The  Interchange  Format  SDIF  can  be  used  by 
applications  requiring  a  SGML  based  clear  text  encoding.  This  latter  interchange  format  is  an  SGML 
application,  called  Office  Document  Language  (ODL).  For  the  purposes  of  interchange,  the  ODL  ENTITIES 
are  placed  in  an  ASN.1  wrapper,  as  defined  by  SDIF.  Each  encoding  form  has  inherent  advantages. 
Conversion  of  document  encoded  in  one  interchange  format  into  the  other  should  not  produce  the  loss  of 
semantic  document  information. 


The  value  of  the  document  profile  attribute  "interchange  format"  for  this  interchange  format  Is  'if-a'.  This  form 
of  ODIF  is  defined  in  ISO  8613-5. 

The  encoding  is  in  accordance  with  the  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
as  defined  in  ISO  8825. 


8.1.2       DAP  Identifier 

The  value  for  the  document  profile  attribute  "Document  application  profile"  for  this  interchange  format  is 
represented  by  the  following  object  identifier. 

Editor's  Note  -  To  be  supplied. 


8.1.3       Encoding  of  Application  Comments 

ISO  8613-5  define  the  encoding  of  the  attribute  Application  Comments  as  an  octet  string.  For  SpecificBlock, 
this  DAP  requires  that  the  encoding  within  that  octet  string  be  in  accordance  with  the  ASN.1  syntax  specified 
in  the  following  module  definition. 

NISTpDAPSpecification 

DEFINITION!  ::=  BEGIN 

EXPORTS  Object-Appl-Comm-Encoding; 

Object-Appl-Comm-Encoding  ::=  SEQUENCE  OF  INTEGER 


8.1 


Interchange  Format  Class  A 


8.1.1 


Interchange  Format 


END 
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8.2.1       Interchange  Format 

The  document  profile  attribute  "Interchange  format"  does  not  apply  for  this  interchange  format.  The  SDIF 
encoding  of  ODA  is  defined  in  Annex  E  of  ISO  8613-5.  In  addition.  ISO  8613-6,  -7,  and  -8  contain  additional 
specifications  for  this  encoding  of  ODA. 


8.2.2       DAP  identifier 

The  value  for  this  attribute  "Document  application  profile"  for  this  interchange  format  is  represented  by  the 
following  object  identifier. 

Editor's  Note  -  To  be  supplied. 


8.2.3       Encoding  of  Application  Comments 

For  SpecificBlock,  the  encoding  of  the  attribute  "Application  comments"  is  defined  in  a  data  stream 
conforming  to  this  profile  with  the  following  DTD  definition: 

<!DOCTYPE  odaac  [ 
<!-- 

<!DOCTYPE  doc  PUBLIC  "-//USA-OIW//SGML  ENCODED  ODA  APPLICATION 
COMMENTS//EN">  ~> 

<  lELEMENT  objappc    -  O  {#PCDATA)  > 

<!--  Object  application  comment  ~> 

]> 


8.3      Encoding  of  Raster  Content  Information 

The  encoding  of  raster  content  information  in  the  bitmap  encoding  scheme  is  that  specified  in  9.3  of  the 
raster  graphics  content  architecture  part  of  ISO  8613-7,  that  is,  the  first  pel  in  the  order  of  bits  is  allocated 
to  the  most  significant  bit  of  an  octet.  The  encoding  of  the  code  words  in  the  Group  4  facsimile  encoding 
scheme  is  such  that  the  first  or  only  bit  of  the  first  code  word  shall  be  placed  in  the  least  significant  bit  of 
the  first  octet.  Subsequent  bits  of  the  first  and  following  code  words  are  placed  in  the  direction  of  more 
significant  bits  in  the  first  and  following  octets. 
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Annex  A  (normative) 
Amendments  and  Corrigenda 

A.1  Amendments 

A.1.1       Amendments  to  the  base  standard 

The  amendments  applicable  to  this  DAP  includes  the  ISO  8613  -  Amendment  1:  1990.  This  amendment 
includes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

a)  Annex  E:  Use  of  ISO/IEC  10021  (MOTIS)  to  interchange  documents  conforming  to  ISO  8613; 

b)  Annex  F:  Document  application  profile  proforma  and  notation; 

c)  Annex  G:  Conformance  testing  methodology; 

d)  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Corrigenda  1. 

This  DAP  does  not  include  the  following  features  of  the  amendment: 

a)  Addendum  on  security; 

b)  Addendum  on  styles; 

c)  Addendum  on  alternative  representation. 

Additionally,  this  DAP  includes  features  from  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613-7,  ISO/IEC 
JTC1  /SC18/WG5  901 ,  dated  September  1990.  A  new  version  of  ISO  8613-7  which  also  will  incorporate  the 
Colour  Addendum  is  scheduled  to  be  issued  in  1992. 

A.2  Corrigenda 

A.2.1       Corrigenda  to  this  DAP 

There  arc  no  oorrigonda  to  thio  DAP.Ttiis  version  of  the  document  (June  1992)  tn«ji0i|K»ates::iefilft0^^ 
technical  ctenges  approved  at  the  March  1992  ODA  SIG  meeting.  Technical  changes  loctude:  add  Mow  0f 
COTT  T,4  $upport,  i?tiahge  basic  valui?  support  for  page  «izes  and  pel  spacjng,  and  addition  tjl  posltlor*  ahd 
dimension  features.  These  changes  were  made  to  atign  more  closely  with  FOD36  DAP*  harmonize  with 
PAGODA;  and  support  Association  for  information  and  Image  ivfanagement  (AilM)  requirerrientsi 
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Annex  B  (informative) 
Recommended  Practices 


B.1      Transfer  methods  for  ODA 


B.1.1       Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  the  definition  given  below: 


OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters,  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIFIER, 
document-architecture-class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processable  (2)  } 
OdaData  ::-    SEQUENCE  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part  with  tag  12: 
Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  However,  this  is  out 
of  the  scope  of  this  profile. 


B.1.2      Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  FTAM  Document  Type  to  be  used  for  minimal  storage  and  transfer 
capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced  capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  FTAM-3,  "ISO  RAM  Unstructured  Binary",  document  type 
should  be  specified.  However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to 
know  that  a  given  file  contains  an  ODA  data  stream. 
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B.1.3       Conveyance  Of  ODA  over  DTAM 

This  recommendation  provides  for  information  concerning  tlie  intercliange  of  ODA  based  documents  with 
DTAM  (Document  Transfer  and  Manipulation)  protocols. 

DTAM  is  defined  in  the  T.430-Series  of  recommendations  and  is,  lil<e  ODA.  an  integral  part  of  the  T.400- 
Series  of  CCITT  Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Series  of  recommendations  contain  Communication  Application  Profiles  (CAP).  Recommendation 
T.522  describes  the  Communication  Application  Profile  BT1  for  document  bulk  transfer.  Recommendation 
T.522  is  applicat>le  for  the  Office  Document  Format  Profile  (FOD)  published  in  this  ISP. 

NOTE  -  The  use  of  BT1  within  the  end-toend  oriented  Telematic  Services  Telefax  4  and  Teletex  is  described 
in  7.1  of  Recommendation  T.561  and  7.1  of  Recommendation  T.562. 

B.1.4       Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Flexible  Disk  Cartridges  is  by  the  use  of  an  annex  to  ISO  8613-1  (to  be  published), 
Receding  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293.  This 
annex  provides  for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293,  Volume  and 
File  Structure  of  Flexible  Disk  Cartridges  for  Information  Interchange. 

NOTE  -  Document  encoded  in  ODL  can  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  can  be  stored  in  a  single  file. 

B.2      Font  reference 

The  recommended  method  for  specifying  a  font  reference  is  to  be  based  on  ISO  9541 .  Such  a  reference 
is  to  be  specified  by  the  following  ASN.I  encoding. 

Fonts-Reference      ::=        SET  { 

user-visible-name  (0)  IMPLICIT  Comment-String  OPTIONAL, 

user-readable-comment  (1)  IMPLICIT  Comment-String  OPTIONAL, 
reference-attributes  (2)  IMPLICIT  SET  OF  SET  { 

precedence-number  (0)  IMPLICIT  INTEGER  OPTIONAL, 

attributes  (1)  IMPLICIT  Font-Attribute-Set, 

user-readable-comment        (2)  IMPLICIT  Comment-String  OPTIONAL  } 

} 

Font  sizes  from  6  to  72  points  (100  to  1200  BMU)  are  intended  to  be  supported  by  implementation 
conforming  to  this  informative  recommendation.  All  other  values  of  font  sizes  may  additionally  be  supported, 
but  implementations  may  also  support  using  some  form  of  "fallback". 

The  minimum  font  properties  and  values  from  ISO  9541  that  are  to  be  specified  in  a  Font-Attribute-Set  be 
those  specified  by  the  following  document  application  profile  notation. 

Font-Attribute-Set  { 

PERM     Fontname  {ANYVALUE}, 
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PERM 
PERM 
PERM 
PERM 
PERM 
PERM 
PERM 


PERM 
PERM 


PERM 


PERM 


PERM 
PERM 


Standardversion 

Dsnsource 

Fontfamily 

Posture 

Weight 

Propwidth 

Glyphcomp 

PERM  #inclgyphcols 

PERM  #exclgyphcols 

PERM  #inclgyphs 

PERM  #exclgyphs 

Dsnsize 

Minsize 

PERM  Enumerator 
PERM  #denominator 
Maixsize 

PERM  Enumerator 

PERM  #denominator 

-  BMU  Units  equivalent  to  range  of  6. 

Dsngroup 

PERM  #group-code 
PERM  #subgroup-code 
PERM  #specific-group-code 
Structure 
Wrmodes 

PERM  #wrmodename 
PERM  #nomescdir 
PERM  #esclass 
PERM  #avgescx 
PERM  #avgescy 


{-  To  be  supplied  -}, 

{ANYVALUE}, 

{ANYVALUE}. 

{'upright'  |  'italic-forward'}, 

{'light'  I  'medium'  |  'bold'}, 

{ANYVALUE}, 

{ 

{ANYVALUE}, 
{ANYVALUE}, 
{ANYVALUE}, 
{ANY  VALUE}  }, 

{ANYVALUE}, 

{ 


{ 


{1}  }. 


{100  ..  1200}. 


{100  ..  1200}, 


{1}  }. 
72  point  sizes  - 

{ 

{ANY_VALUE}. 
{ANYVALUE}, 
{ANY  VALUE}  }, 

{ANY_VALUE}, 

{ 

{ANY_VALUE}, 

{'0-degrees' 
{ANYVALUE}, 
{ANYVALUE}, 
{ANY  VALUE}  } 


'90-degrees'  |  '180-degrees'  |  '270-degrees'}, 


B.3      ISO  8632  (CGM)  constraints  for  this  DAP 

It  is  recommended  that  geometric  graphics  content  information  contain  only  those  elements  listed  In  this 
portion  of  the  document,  in  addition  to  the  constraints  imposed  by  ISO  8613-8.  It  is  believed  that  this  subset 
of  the  CGM  is  sufficiently  implemented  to  enable  interworking  of  geometric  graphics  for  application 
conforming  this  document  application  profile. 

Where  an  element  has  parameters,  recommended  constraints  on  the  values  are  given.  The  "-"  symbol 
indicates  that  there  is  no  recommended  constraint. 

Requirements  in  ISO  8632  and  ISO  8613-8  concerning  mandatory  elements,  parameters  must  be  fulfilled. 


B.3.1       Delimeter  elements 

No-Op  See  Note  1 

Begin  Metafile  See  Note  2 

End  Metafile 

Begin  Picture  See  Note  2 

Begin  Picture  Body 
End  Picture 
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B.3.2       Metafile  descriptor  elements 

Metafile  Version  1 

Metafile  Description  See  Notes  2,  3 

VDC  Type 

Integer  Precision  8,  16 

Real  Precision  (0.9.23),  (1.16.16) 

Index  Precision  16 

Colour  Precision  8,  16 

Colour  Index  Precision  8,  16 

Maximum  Colour  Index 

Colour  Value  Extent 

Metafile  Element  List 

Font  List 

Character  Set  List  See  Note  5 

Character  Coding  Announcer  0.  (basic-7-bit),  (basic-8-bit) 


B.3.3       Picture  descriptor  elements 

Scaling  Mode  See  Note  6 

Colour  Selection  Mode 

Line  Width  Specification  Mode 

Marker  Size  Specification  Mode 

Edge  Width  Specification  Mode 

VDC  Extent 

Background  Colour 


B.3.4       Control  elements 

VDC  Integer  Precision  16,32 

VDC  Real  Precision  (0,9.23),  (1,16.16) 

Auxiliary  Colour 

Transparency 

Clip  Rectangle 

Clip  Indicator 


B.3.5       Graphical  primitive  elements 

Polyline  See  Note  7 
Disjoint  Polyline  See  Note  7 

Polymarker  See  Note  7 

Text  See  Note  2 
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Restricted  Text  See  Notes  2,  8 

Append  Text  See  Notes  2,  8 

Polygon  See  Note  7 

Polygon  Set  See  Note  7 

Cell  Array  See  Note  9 

Rectangle 

Circle  - 
Circular  Arc  3  Point 

Circular  Arc  3  Point  Close  ~ 

Circular  Arc  Centre 

1  Circular  Arc  Centre  Close 

Ellipse 

Elliptical  Arc 

Elliptical  Arc  Close 


B.3.6       Attribute  elements 


Line  Bundle  Index 

Line  Type 

Line  Width 

Line  Colour 

Marker  Bundle  Index 

Marker  Type 

Marker  Size 

Marker  Colour 

Text  Bundle  Index 

Text  Font  Index 

Text  Precision 

Character  Expansion  Factor 

Character  Spacing 

Text  Colour 

Character  Height 

Character  Orientation 

Text  Path 

Text  Alignment 

Character  Set  Index 

Alternate  Character  Set  Index 

Fill  Bundle  Index 

Interior  Style 

Fill  Colour 

Hatch  Index 

Pattern  Index 

Edge  Bundle  Index 

Edge  Type 

Edge  Width 

Edge  Colour 

Edge  Visibility 


1-5 
1-5 

positive 

1-5 
1-5 


1-5 


positive 


1-5 


1-6 

1  ..  8,  nx  1-16,  ny  1-16 

1-5 

1-5 

positive 
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Fill  Reference  Point 

Pattern  Table  See  Notes  10,  1 1 

Pattern  Size 

Colour  Table  Specification  See  Notes  12,  13 

Aspect  Source  Flags 


B.3.7       External  elements 

Message  No  action 

Application  Data  See  Note  2 


NOTE- 

1.  An  arbitrary  sequence  of  n  octets.  Where  n=0,  1, ..,  32767.  The  sequence  of  zero  or  more  octets  is  for  padding 
purposes. 

2.  The  string  ocurring  in  the  parametric  list  of  this  element  shall  not  contain  more  than  254  characters,  except  for 
data  records  where  the  string  shall  not  contain  more  than  32767  characters. 

3.  There  will  be  exactly  one  METAFILE  DESCRIPTION  element  in  the  metafile.  The  METAFILE  DESCRIPTION  string 
parameter  will  be  used  to  include  the  sub-string  "ISO  FCG13"  to  label  the  content  information  as  conforming 
to  this  agreement.  In  addition,  the  METAFILE  DESCRIPTION  element  should  include  a  sub-string  that  identifies 
the  generator  of  this  metafile,  including  company,  product,  and  product  version. 


4.  The  only  character  sets  that  may  be  specified  are  those  specified  for  character  content  portions.  Refer  to  7. 1 , 

Document  Profile  Constraints,  for  further  detail  on  which  character  sets  are  supported  by  this  document 
application  profile.  The  default  character  set  for  geometric  graphics  content  is  the  same  as  the  default  character 
set  for  character  content  architecture. 


5.  The  Scale  Factor  parameter  of  SCALING  MODE  element  is  always  a  32-bit  floating  point  value,  even  when  the 

REAL  PRECISION  has  selected  fixed  point  for  other  real  numbers.  It  is  not  apparent  in  ISO  8632  what  the 
precision  of  this  floating  point  value  is  when  fixed  point  has  been  selected.  Its  precision  shall  be  (0,9,23). 


6.  The  maximum  number  of  points  of  this  element  shall  be  1024. 


7.  The  complete  restricted  text  string,  including  any  appended  text,  shall  be  included  in  a  metafile  conforming  to 
this  agreement.  The  complete  restricted  text  string  shall  be  scaled  isotropically  such  that  the  specified  aspect 
ratio  for  the  text  is  not  distorted  and  the  string  fits  into  the  text  extent  parallelogram.  String  of  parameters  shall 
not  contain  any  control  characters  except  as  allowed  by  and  necessary  to  implement  the  character  set  switching 
modes  which  can  be  selected  by  basic  values  of  CHAR  CODE  ANNOUNCER. 

8.  The  maximum  number  of  colour  values  that  can  appear  in  the  colour  list  parameter  for  the  CELL  ARRAY 
element  shall  be  1048576  (one  1024  x  1024  image). 


9.  The  PATTERN  TABLE  element  shall  appear  prior  to  any  graphical  primitive  element  to  assure  that  interpreting 
systems  without  dynamic  pattern  update  can  render  the  intended  effect.  Once  a  given  pattern  representation 
is  specified  and  used,  it  shall  not  be  respecified. 

10.  Colour  Array  parameter  for  the  PATTERN  TABLE  element  is  2048.  This  will  support  8  patterns  of  16x16.  The 
maximum  number  of  colour  values  that  can  appear  in  a  colour  array  parameter  shall  be  256  for  each  PATTERN 
TABLE  element  (one  16  x  16  pattern)  and  2048  for  the  complete  pattern  table  itself  (eight  16  x  16  patterns). 

1 1 .  The  COLOUR  TABLE  element  shall  appear  prior  to  any  graphical  primitive  elements  to  assure  that  interpreting 
systems  without  dynamic  colour  update  can  render  the  intended  effect.  Once  a  given  colour  representation  is 
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specified  and  used,  it  shall  not  be  respecified.  For  indexed  colour  selection,  either  background  colour  or  all 
colour  indexes  in  the  metafile  shall  have  their  representations  specified  or  none  shall.  Colour  indexes  shall  be 
specified  by  the  COLOUR  TABLE  element.  Background  colour  shall  be  specified  either  by  the  BACKGROUND 
COLOUR  element  or  the  the  colour  index  0.  For  direct  colour  selection,  either  the  background  colour  or  the 
colour  of  each  displayed  primitvie  shall  be  explicitly  specified,  or  none  shall  be  specified.  In  other  words,  either 
all  colours  shall  be  defaulted  or  none  shall  be  defaulted. 

12.         The  maximum  number  of  colour  values  that  can  appear  in  the  Colour  List  parameter  for  the  COLOUR  TABLE 
element  is  64.  This  will  support  a  63  entry  colour  table. 


B.4     Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879,  SGML)  b>ased  systems  and  systems  based  on  this  ODA  document  application  profile 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL).  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  base  standard.  Such  a  representation  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile. 
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Annex  C  (informative) 

References  to  Other  Standards  and  Registers 

[I]  CCITT  Recommendation  T.400  :  1988,  Introduction  to  Document  Architecture,  Transfer  and 
Manipulation; 

[2]       CCITT  Recommendation  T.41 1 : 1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  General  Principles; 

[3]       CCITT  Recommendation  T.41 2 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Structures; 

[4]       CCITT  Recommendation  T.41 4 : 1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

[5]       CCITT  Recommendation  T.41 5 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Open  Document  Interchange  Format; 

[6]       CCITT  Recommendation  T.41 6 : 1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Character  Content  Architecture; 

[7]       CCITT  Recommendation  T.41 7 : 1 988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Raster  Graphics  Content  Architecture; 

[8]       CCITT  Recommendation  T.41 8 : 1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Geometric  Graphics  Content  Architecture; 

[9]       CCITT  Recommendation  T.502  :  1990,  Document  Application  Profile  PM-11  for  the  Interchange  of 
Character  Content  Documents  in  Processable  and  Formatted  Forms; 

[10]     CCITT  Recommendation  T.503  :  1984,  Document  Application  Profile  for  the  Interchange  of  Group 
4  Facsimile  Documents; 

[II]  CCITT  Recommendation  T.505  :  1990,  Document  Application  Profile  PM-26  for  the  Interchange  of 
Enhanced  Mixed  Content  Documents  in  Processable  and  Formatted  Forms; 

[12]      ISO  8571  :  1988,  Information  processing  systems  -  Open  Systems  Interconnection  -  File  transfer, 
access  and  management; 

[13]      ISO  9070  :  1990,  Information  processing  -  SGML  support  facilities  -  Registration  procedures  for 
public  owner  identifiers; 

[14]      ISO/TR  9573  : 1988,  Information  processing  -  SGML  technical  report  -  Techniques  for  using  SGML; 

[15]      ISO  10021  :  (to  be  published).  Information  processing  systems  -  Text  communication  -  Message 
Oriented  Text  Interchange  System; 
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[16]     ISP  F0D1 1  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  basic  function 
character  content  document  in  processabie  and  formatted  forms; 

[17]     ISP  FOD26  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  enhanced 
function  mixed  content  documents  in  processabie  and  formatted  forms; 

[18]     ISP  FOD36  :  (to  be  published).  Office  document  format  profile  for  the  interchange  of  extended 
function  mixed  content  documents  in  processabie  and  formatted  forms; 

[19]      MIL-R-28002A  :  1990.  MIUTARY  SPECIFICATION,  RASTER  GRAPHICS  REPRESENTATION  IN 
BINARY  FORIVIAT,  REQUIREMENTS  FOR. 
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Annex  D  (informative) 

Supplementary  Information  on  Attributes 


Table  D.I  Content  coding  attributes 


Attributes 

Basic  values 

Default  values 

Non-basic 
values 

Numhar-of-nalfi-nsr-lins 

Ml  iy  L^vOlllv^  II  li^Uwl 

None 

None 

Number-of-lines 

any  positive  integer 

None 

None 

Tiling-offset* 

(any  non-negative  integer 
<  512,  any  non-negative 
integer  <  512) 

(0,0) 

None 

Tile-types*  ■ 

T.6  encoded,  bitmap 
encoded,  null 
background,  null 
foreground 

T.6  encoded 

None 

Type-of-coding 

T.6  encoding  (untiled), 
bitmap  (untiled),  tiledisiii4 
ID  ««odmgr  T.4  2D 

T.6  encoding 

None 

Tutorial  Note  -  *  Only  used  if  Type-of-coding  is  "tiled" 


Table  D.2  Presentation  attributes 


Attributes 

Basic  values 

Default  values 

Non-basic  values 

Pel-path 

0,  90  deg 

0  deg 

180,  270  deg 

Line-progression 

270  deg 

270  deg 

90  deg 

Pel-spacing 

6  BMU  (200),  "1  BMU 

4  BMU  (300) 

Any  value 

mi^12,  a,  6.  S,  4,3, 

*null' 

Clipping 

Two  Coord.  Pairs  (any 
non-negative  integer,  any 
non-negative  integer) 

(0,0),  (N-1,  L-1) 

None 
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Table  D.3  Document  profile  attributes 


Attribute 

Class 

Permissible  values 

Specific-layout-structure 

m 

present 

Presentation-styles 

nm 

present 

Document-characteristics 

M 

Document-architecture-class 

m 

formatted 

Document-application-profile 

m 

{-  See  clause  8  for  a  definition  of  the 
permitted  values  for  this  attribute.  -} 

Content-architecture-classes 

m 

{2  8  2  7  2},  {2  8  2  8  0}.  {2  8  2  6  0} 

Interchange-format-class 

m 

A 

\JUr\'yxsl  olUl  1 

1  1 1 

l^UL^UiTlol  U'ctI  v^iillOvJlUi  o~U6TaUllo 

M 

our  uc?ru-dicriiiouiijr6~(jicidS 

m 

Type-of-coding 

«m 

T.6  Encoding^  (default)  Tiled  Encoding 

Page-dimensions 

nm 

See  list  in  table  1,  (Default  value  is  NA- 

ivi  eu  1  u  m-iy  pes 

nm 

oee  iisi  in  lauie  i ,  (uerauri  vaiue  is  ixm- 
A,  9240  X  13200  BMU) 

Page-position 

nm 

any  coordinate  pair  within  page 

R  aster-g  r-content-defau  Its 

NM 

Pel-path 

nm 

0,  90,  180,  270  degrees  (0  is  normal 

Line-progression 

nm 

90,  270  degrees  (270  is  normal  default) 

Clipping 

nm 

any  coordinate  pair  w/ithin  page 

Pel-spacing 

nm 

6  BMU  (200  pole/in.)  or  .1  BMU  (300 
pelc/in.),16,  12,  8,  6.  $,  4,  3,  2,  Of  t 
mm  (Normal  default  is  4  BMU) 

Spacing  Ratio 

nm 

Any  value 

Non-basic-doc-characteristics 

NM 

Page-dimensions 

nm 

See  table  1 ,  NA  F  through  NA  K,  roll 
p3pQr 

Medium-types 

nm 

See  table  1 ,  NA  F  through  NA  K,  roll 
p3pQr 
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Table  D.3  Document  profile  attributes  (concluded) 


Attribute 

Class 

Permissible  values 

Raster-gr-presentation-features 

NM 

Pel-path 

nm 

180,  270  degrees 

Line-progression 

nm 

90  degrees 

Pel-spacing 

nm 

Any  value  except  6  BMU  (200  pele/in.) 
or  A  BMU  (300  polc/in.)16.  12,  8, 6,  5, 
4,  3.  2,  or  1  BMU 

Document-management-attributes 

M 

Document  Reference 

m 

Any  string  of  characters 

The  following  notation  is  used  in  the  class  column  of  this  table: 
m   mandatory  attribute  nm  non-mandatory  attribute  d   defaultable  attribute 

Capital  letters  (M,  NM,  and  D)  are  used  for  groups  of  attributes. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Office  Document  Architecture  (ODA) 
Special  Interest  Group  (SIG)  of  the  Open  Systems  Intoroonnootion  En\^orwr>6rft  Implementors'  Workshop 
(OIW).  Development  of  this  document  application  profile  has  been  done  In  liaison  with  several  organizations. 
These  include  the  DoD  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  Office,  Navy's  David  Taylor 
Research  Center,  and  the  ad-hoc  Tiling  Task  Group. 

This  document  application  profile  is  intended  to  be  suitable  for  the  interchange  of  large  format  raster  images. 
This  part  contains  four  annexes: 

a)  annex  A  (normative):  Addenda  and  errata  Aniendments  mid  ccsrlgeoda; 

b)  annex  B  (informative):  Recommended  practices; 

c)  annex  C  (informative):  References  to  other  standards  and  registers; 

d)  annex  D  (informative):  Supplementary  information  on  attributes. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struckout.  New  and  replacement  text  will  be  shown  as 
shaded. 

This  psff.  uses  a  conv»itk»i  of  dotit^e  arttf  ^Ingte  qudtes,  ti^t  has  be&n  estal^&hed  by  ISO  lor  me  in  ^6 
ODA  t^tmi^Tti  and  r^e^ted  <JooipJiefit  appilcecHon  i^rofiies.  ttie  cc«Tven$bft  h  to  v^Wit  ^  tex* 
doyble  qucsm  ta  acceimiat&  ODA  attributes  fmtm  aid  single  qiiotds  to  acc^iSuMe         for  Siose 


ii 


PART  23  -  ODA  Raster  DAP 


September  1992  (Stable) 


Table  of  Contents 

Part  23  -  ODA  Raster  DAP   1 

0  Introduction   1 

1  Scope     fletd  of  appHcatlonft   i 

2  Normative  references    2 

2.1  ISO   2 

2.2  CCITT   3 

3  Definitions  and  terminology    3 

3.1  Definitions   3 

3.2  Constituent  names    3 

4  Relationship  to  other  DAPs   4 

5  Conformance   4 

5.1  Data  stream  conformance   4 

5.2  Implementation  conformance   5 

6  Characteristics  supported  by  this  DAP    5 

6.1  Overview    5 

6.2  Logical  constituents    6 

6.3  Layout  constituents   6 

6.3.1  Overview  of  the  layout  characteristics    6 

6.3.2  DocumentLayoutRoot   6 

6.3.3  Page  characteristics   7 

6.3.3.1  CompositePage    7 

6.3.3.2  Page  dimensions    7 

6.3.3.3  Nominal  page  sizes    8 

6.3.4  ImageFrame   8 

6.3.5  SpecificBlock   8 

6.4  Document  layout  characteristics    10 

6.5  Content  layout  and  imaging  control   10 

6.5.1           Raster  graphics  content    11 

6.5.1.1  Introduction    11 

6.5.1.2  Raster  graphics  content  architecture   11 

6.5.1.3  Raster  graphics  encoding  methods   11 

6.5.1.4  Raster  presentation   12 

6.6  Miscellaneous  features    13 

6.7  Document  management  features   13 

7  Specification  of  constituent  constraints      14 

7.1       Document  profile  constraints   14 

7.1.1            Macro  definitions    14 

Mi 


PART  23  -  ODA  Raster  DAP 


September  1992  (Stable) 


7.1.2           Constituent  constraints   18 

7.1.2.1         DocumentProfile   18 

7.2  Logical  constituent  constraints   20 

7.3  Layout  constituent  constraints   20 

7.3.1  Macro  definitions    20 

7.3.2  Factor  constraints   20 

7.3.3  Constituent  constraints   21 

7.3.3.1  DocumentLayoutRoot   21 

7.3.3.2  ComposltePage    21 

7.3.3.3  InfiageFrame   21 

7.3.3.4  SpeclficBlock   21 

7.4  Layout  style  constraints   22 

7.5  Presentation  style  constraints    22 

7.5.1  Macro  definitions    22 

7.5.2  Factor  constraints   22 

7.5.3  Presentation  style  constituent  constraint    23 

7.5.3.1          PStyle   23 

7.6  Content  portion  constraints   23 

7.6.1  Macro  definitions    23 

7.6.2  Factor  constraints   23 

7.6.3  Content  portion  Ck»istttii0nt  constraints   23 

7.6.3.1         Raster  graphics  content  portion   23 

7.7  Additional  usage  constraints    24 

8      Interchange  format    24 

8.1  Interchange  format  ODIF  <class  A)   25 

8.1.1  Interchange  format   25 

8.1.2  DAP  identifier   25 

8.1.3  Encoding  of  application  comments    25 

8.2  Interchange  format  SDIF   25 

8.2.1  Interchange  format   25 

8.2.2  DAP  identifier   26 

8.2.3  Encoding  of  application  comments    26 

8.3  Encoding  of  raster  content  information   26 

Annex  A  (normative) 

Amendments  and  corrigenda    28 

A.1      Amendments    28 

A.  1.1           Amendments  to  the  base  standard    28 

A.  2      Corrigenda   28 

A.  2.1           Corrigenda  to  this  DAP   28 

Annex  B  (informative) 

Recommended  practices    30 

B.  I      Transfer  methods  for  ODA   30 

B.  1.1           Conveyance  of  ODA  over  CCITT  X.400-1 984    30 

B.I. 2           Conveyance  of  ODA  over  FTAM    30 

iv 


PART  23  -  ODA  Raster  DAP  September  1 992  (Stable) 

B.I. 3  Conveyance  of  ODA  over  DTAM   31 

B.1.4  Conveyance  of  ODA  over  flexible  disks   31 

8.2      Interoperability  with  SGML  applications    31 

Annex  C  (Informative) 

References  to  other  standards  and  registers    32 

Annex  D  (Informative) 

Supplementary  information  on  attributes    33 

Annex  E  (informative) 

Register  index   36 


V 


PART  23  -  ODA  Raster  DAP  September  1992  (Stable) 

List  of  Figures 

Figure  1  -  Constituents   6 

Figure  2  -  Document  layout  structure   7 


vi 


PART  23  -  ODA  Raster  DAP 


September  1992  (Stable) 


List  of  Tables 

Table  1  -  Dimensions  for  various  page  sizes   9 

Table  2  -  Layout  attributes   10 

Table  D.1  -  Content  coding  attributes   33 

Table  D.2  -  Presentation  attributes   33 

Table  D.3  -  Document  profile  attributes    34 

Table  E.1  -  Object  identifiers   36 


vi! 


I 


Part  23  -  ODA  Raster  DAP 


0  Introduction 

This  is  tlie  definition  of  a  specification  for  an  Open  Document  Architecture  (ODA)  Document  Application 
Profile  (DAP)  named  ODA  Raster  DAP.  This  DAP  is  suitalDle  for  interchanging  documents  in  formatted  form. 
The  documents  contain  only  raster  graphics  images. 

There  are  two  DAP  object  identifiers  supporting  this  DAP  with  the  only  difference  being  in  the  encoding  of 
the  data  stream.  One  uses  the  ASN.1  based  ODIF  encoding.  The  other  uses  the  SGML/SDIF  based  ODL 
encoding.  When  this  document  refers  to  this  profile,  it  is  referring  to  this  specification  regardless  of  which 
DAP  identifier  may  be  selected  to  create  the  data  stream. 

This  DAP  has  been  prepared  by  the  ODA  Special  Interest  Group  ^$10)  of  the  National  inotituto  of  Standardo 
and  Technology  (MIST)  Open  Systems  Intoroonnootion  (OSI)  Enviromnen^  Implementors^  Worl<shop  (OIW). 
The  DAP  is  defined  in  accordance  with  ISO  8613-1  and  CCiTTT.<111  and  follows  the  standardized  proforma 
and  notation  defined  in  ISO  8613-1  Annex  F.  The  DAP  is  based  on  ODA  as  defined  in  ISO  8613  and  the 
Tiled  Raster  Graphics  Addendum  to  ISO  8613,  Part  7. 


1    Scope  mi4  field  of  appllcaHons 

This  DAP  specifies  an  interchange  format  suitable  for  transfer  of  structured  documents  between  equipment 
designed  for  raster  processing.  The  documents  supported  by  this  DAP  are  based  on  a  paradigm  of  an 
electronic  engineering  drawing  or  illustration.  Such  documents  contain  one  or  more  pages.  Each  page 
consists  of  an  image  in  the  form  of  a  bi-tonal  raster  graphics  content.  There  is  no  restriction  on  the 
minimum  size  of  the  Image. 

This  document  defines  a  DAP  that  allows  large  format  raster  documents  to  be  interchanged  in  a  formatted 
form  in  accordance  with  ISO  8613. 

It  is  assumed  that,  when  negotiation  is  performed  by  the  service  using  this  DAP,  all  non-basic  features  tfalti^ 
are  subject  to  negotiation. 

This  DAP  is  independent  of  the  processes  carried  out  in  an  end  system  to  create,  edit,  or  reproduce  raster 
documents.  It  is  also  independent  of  the  means  to  transfer  the  document  which,  for  example,  may  be  by 
means  of  communication  links  or  exchanged  storage  media. 

The  features  of  a  document  that  can  be  interchanged  using  this  DAP  fall  into  the  following  categories: 

a)  Page  fornnat  features  -  these  concern  how  the  layout  of  each  page  of  a  document  will  appear 
when  reproduced; 

b)  Raster  graphics  layout  and  imaging  features  -  these  concern  how  the  document  content  will 
appear  within  pages  of  the  reproduced  document;-afld 

c)  Raster  graphics  coding  -  these  concern  the  raster  graphics  representations  and  control 
functions  that  make  up  the  document  raster  graphics  content. 
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2     Normative  references  * 

The  following  references  are  required  in  order  to  implement  this  DAP: 

! 

2.1  ISO 

[I]  ISO  861 3-1  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interciiange  Format  -  Part  1:  Introduction  and  General  Principles;  I 

[2]  ISO  861 3-2  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  2:  Document  Structures; 

[3]  ISO  861 3-4  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  4:  Document  Profile; 

[4]  ISO  861 3-5  : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  5:  Open  Document  Interchange  Format; 

[5]  ISO  861 3-7 : 1 989,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  7:  Raster  Graphics  Content  Architectures; 

[6]  ISO  861 3-1  : 1 991 ,  Information  processing  -  Text  and  Office  Systems;  Open  Document  Architecture 
(ODA)  and  Interchange  Format  -  Part  1:Annex  F  -  A  Document  Application  Profile  Proforma  and 
Notation; 

[7]  ISO  861 3-7 :  (to  be  published),  Information  processing  -  Text  and  Office  Systems;  Office  Document 
Architecture  (ODA)  and  Interchange  Format  -  Part  7:  Amendment  -  Tiled  Raster  Graphics  Addendum 
to  ISO  8613,  Part  7; 

C«|  ISO  ;  {i^  be  ptjl^lslifec^,  iaformttonprocos^fig  -  f^&rjd  O^Sj^m$;  t^}(^O0Cmm 
Architedum  (OfSA^  &nd  irtterctmnge  format  *  Part  7i  Anrnndrnmn  -  AddMonsf  M  Cvtier  Msppif^ 

[9]  ISO  8824  :  1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Abstract  Syntax  Notation  One  (ASN.  1); 

[10]  ISO  8825  : 1987,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Specification 
of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1); 

[II]  ISO  8879  : 1986,  Information  processing  -  Text  and  office  systems  -  Standard  Generalized  Markup 
Language  (SGML); 

Language  ^QML^,  Amerv^mem  t 

[13]  ISO  9069  : 1988,  Information  processing  -  SGML  support  facilities  -  SGML  Document  Interchange 
Format  (SDIF). 
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2.2  CCITT 

|14|     l^ecm»««Kteatofi  T.4  J  tl968,  Smndrntikatkm  of  Group  $  Facsfmne  Apparam  lor  Docum&r$ 

[1^]    Recommendation  T.6 : 1988,  Facsimile  Coding  Schemes  and  Coding  Control  Functions  for  Group 
4  Facsimile  Apparatus. 


3     Definitions  and  terminology 


3.1  Definitions 

The  definitions  given  in  ISO  8613-1  are  applicable  to  this  document. 


3.2      Constituent  names 

Each  constituent  that  may  be  included  in  a  document  that  conforms  to  this  profile  has  been  given  a  unique 
name  which  serves  to  identify  that  constituent  throughout  this  profile. 

The  convention  is  that  full  names  are  used  (i.e.,  no  abbreviations  are  used),  two  or  more  words  in  a  name 
are  concatenated  and  each  word  begins  with  a  capital.  Examples  of  constituent  names  used  In  this  profile 
are  CompositePage,  DocumentLayoutRoot,  and  SpecificBlock. 

In  clause  6  of  thio  profile,  each  constituent  provided  by  this  profile  is  underlined  once  at  the  point  in  the  text 
at  which  the  purpose  of  that  constituent  is  defined.  This  also  serves  to  identify  all  the  constituents  provided 
by  this  profile. 

The  same  constituent  names  are  also  used  in  the  technical  specification  in  clause  7  of  thie  profile  so  that 
there  is  a  one-to-one  correspondence  between  the  use  of  these  names  in  clauses  6  and  7. 

Although  the  constituent  names  relate  to  the  purpose  of  the  constituents,  the  semantics  of  constituents  must 
not  be  implied  from  the  actual  names  that  are  used.  Also,  these  names  do  not  appear  in  an  interchanged 
document  but  a  mechanism  for  identifying  constituents  in  an  interchange  document  is  provided.  Thus  in 
an  application  using  this  profile,  the  constituents  may  be  known  to  the  user  by  different  names. 
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4     Relationship  to  other  DAPs 

Functionally,  this  DAP  is  a  functional  superset  of  the  CCITT  Recommendation  T.503,  A  Document  Application 
Profile  for  the  Interchange  of  Group  4  Facsimile  Documents.  This  DAP  is  a  functional  subset  of  Part  22  - 
ODA  Image  DAP. 


5  Conformance 

In  order  to  conform  to  this  DAP,  a  data  stream  representing  a  document  must  meet  the  requirements 
specified  in  5.1. 

The  requirements  for  implementations  that  originate  and /or  receive  data  streams  conforming  to  this  DAP 
are  specified  in  5.2. 


5.1      Data  stream  conformance 

The  following  requirements  apply  to  the  encoding  of  data  streams  that  conform  to  these  agreements: 

a)  The  data  stream  shall  be  encoded  in  accordance  with  the  ASN.1  encoding  rules  defined  in 
ISO  8825  or  the  SGML  encoding  rules  dofinod  in  grarnmar  and  syriSax  of  ISO  8879; 

b)  The  data  stream  shall  be  structured  In  accordance  with  the  interchange  format  defined  in 
clause  8  of  this  DAP; 

c)  The  document  shall  be  structured  in  accordance  with  only  the  formatted  document 
architecture  class  specified  in  clause  7  of  this  DAP.  In  addition,  the  document  shall  contain  all 
mandatory  constituents  specified  for  that  class  and  may  optionally  contain  constituents 
permitted  for  that  class  as  specified  in  clause  7; 

d)  Each  constituent  shall  contain  all  those  attributes  specified  as  required  for  that  constituent  in 
this  profile.  Other  attributes  may  be  specified  provided  they  are  permitted  for  that  constituent; 

e)  The  attributes  shall  have  values  within  the  range  of  permissible  values  specified  in  this  profile; 

f)  The  encoded  document  shall  be  structured  in  accordance  with  the  abstract  document 
architecture  defined  in  ISO  8613-2; 

g)  The  encoded  document  shall  be  structured  in  accordance  with  the  characteristics  defined  in 
clause  6  of  this  DAP  and  shall  contain  only  those  features  defined  in  clause  6. 
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5.2      Implementation  conformance 

This  clause  states  the  requirements  for  Implementations  claiming  conformance  to  this  DAP. 

A  conforming  receiving  implementation  must  be  capable  of  receiving  either  any  data  streams  conforming 
to  this  profile  structured  in  accordance  with  ODIF  or  any  data  streams  conforming  to  this  profile  structured 
in  accordance  with  ODL  or  both  of  these.  Receiving  usually,  but  not  always,  involves  recognizing  and 
further  processing  the  data  stream  elements. 


6     Characteristics  supported  by  this  DAP 

This  clause  describes  the  characteristics  of  documents  that  can  be  represented  by  data  streams  confonning 
to  this  profile.  This  clause  also  describes  how  these  characteristics  are  represented  in  terms  of  divisional 
components  of  the  data  streams. 


6.1  Overview 

This  DAP  describes  the  features  of  ISO  8613  that  are  needed  to  support  the  Interchange  of  documents 
containing  only  raster  graphics  content,  it  specifies  interchange  formats  for  the  transfer  of  structured 
documents  with  simple  layout  structures. 

This  DAP  describes  documents  that  can  be  interchanged  in  the  formatted  form,  which  facilitates  the 
reproduction  of  a  document  as  intended  by  the  originator. 

Only  one  category  of  content  is  allowed  within  the  document,  that  is,  a  raster  graphics  content  in  the 
formatted  processable  form.  This  is  intended  to  facilitate  the  reproduction  of  the  document  content  as 
intended  by  the  originator. 

This  clause  describes  the  layout  features  that  can  be  represented  in  documents  conforming  to  this  DAP. 
The  features  are  described  in  terms  that  are  typical  of  the  user-perceived  capabilities  and  semantics  found 
in  a  raster  document  interchange  environment. 

For  the  purpose  of  interchange,  a  document  is  represented  as  a  collection  of  constituents,  each  of  which 
is  represented  by  a  set  of  attributes.  The  constituents  that  make  up  a  formatted  document  are  defined 
below  in  this  clause  and  are  illustrated  in  figure  1 . 

Constituents  defined  as  required  must  occur  in  any  document  that  conforms  to  this  profile.  Constituents 
listed  as  optional  may  or  may  not  be  present  in  the  document,  depending  on  the  requirements  of  the 
particular  document. 

The  required  constituents  include: 

a)  a  document  profile; 

b)  layout  object  descriptions  representing  a  specific  layout  structure; 
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Document  Profile 


Presentation  Style 
(Optional) 


Specific  Layout 
Structure 


Content  Portion 
Description 


Figure  1  -  Constituents 


6.2      Logical  constituents 

Not  applicable. 


6.3      Layout  constituents 

This  clause  describes  the  features  of  the  layout  objects  that  can  be  represented  in  documents  conforming 
to  this  DAP. 


6.3.1       Overview  of  tlie  layout  characteristics 

The  document  structure  allows  the  document  content  to  be  laid  out  and  presented  in  one  or  more  pages. 
Each  page  in  a  document  consists  of  only  a  single  raster  graphics  content  representing  an  engineering 
drawing,  illustration,  or  other  raster  scanned  image. 

A  specific  layout  structure  of  the  document  conforming  to  this  application  profile  consists  of  a  four-level 
hierarchy  consisting  of  a  document  layout  root,  composite  pages,  frames,  and  bloci<s.  The  document  can 
consist  of  multiple  composite  pages  where  each  page  represents  a  single  image.  Each  composite  page 
consists  of  a  frame  which  in  turn  contains  a  block  containing  the  content  associated  with  the  image. 

Figure  2  is  an  illustration  of  the  features  of  the  document  layout  structure  supported  by  this  DAP. 


6.3.2  DocumentLayoutRoot 

A  Documentl-ayoutRoot  is  the  top  level  in  a  document  layout  structure.  A  DocumentLayoutRoot  consists 
of  a  sequence  of  one  or  more  CompositePage  constituent  constraints. 
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Document 
Layout  Root 


Composite 
Pages ( s ) 

I 


Image 
Frame 


Specific 
Block 


Figure  2  -  Document  layout  structure 


6.3.3       Page  characteristics 

Only  one  constituent  constraint  is  provided  to  present  pages  within  a  document. 

A  document  consists  of  a  sequence  of  one  or  more  composite  pages.  In  a  document's  composite  page, 
a  frame  is  used  to  position  a  single  raster  graphics  content  representing  the  image  on  the  page. 

A  document  may  consist  of  multiple  pages  of  different  sizes.  Each  page  may  be  either  landscape  or  portrait 
orientation.  Both  orientations  are  permitted  in  the  document. 


6.3.3.1  ComposltePage 

A  CompositePage  is  a  constituent  constraint  which  defines  a  composite  page  that  corresponds  to  the  page 
area  used  for  presenting  the  sequence  of  an  ImageFrame  frame. 


6.3.3.2        Page  dimensions 

A  wide  variety  of  page  dimensions  are  supported  including  large  format  raster  documents.  The  dimensions 
of  the  pages  may  be  specified  as  any  value,  in  BMU  measurement  units,  including  the  larger  sizes  produced 
from  foldout-size  Images  and  roll  paper.  These  sizes  apply  to  both  portrait  and  landscape  orientations.  The 


page  sizes  include:  ISO  A0-A5,  A-4<, 

Japanese  legal  and  tetter. 

fbldoata  27.^ 

cm  (11  in.)  X  36.56  era 

(14  In.)  and  27.84  <5m  (1 1  itt)  X  43.18  cm 

(17      and  27.9*  <sta  <l  t      roa  paper. 

Seet 

abte  1. 

Dimonoiono  oqulvalont  to  or  Iogg  than  the  actual  (nominal)  page  oizoo  of  ANSI  E  in  both  portrait  and 
landooapo  oriontationo  arc  baoio  values.  Larger  dimonoiono  (F  K)  including  thooo  produced  from  roll  paper 
are  non  booio  and  their  uoo  must  bo  indicated  in  the  dooumont  profile  Although  ISO  AO  A4  oizoo  arc  not 
gonorally  used,  the  A1  A4  oizoo  do  fall  within  the  range  of  the  ANSI  E  oigoo  and  thoroforo  could  be 
oonoidorod  baoio  values  (Sec  table  2).  AO  size  lo  a  non  basic  value. 


D&iierjgloft$  equivalent  to  or  tlian  th«  <JOintBon  as$ared  reproduction  area  {CAi^ A)  of  ISO  A4  and  North 
^Twrlcao  letter  {HfiA^    portraft  or  landscape  <»fentation  are  basic  values.  Larger  page  sizes  mduding 
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The  default  dimensions  are  the  Common  Aoourod  Roproduotion  Aroa  (CARA)  of  North  American  Letter  (A). 
Any  default  page  dimensions  may  be  specified  in  the  document  profile  subject  to  the  maximum  dimensions 
defined  above  by  using  the  |Riage  dimensions*  attribute.  The  iRiage  positior|  attribute  may  be  used  to 
specify  the  position  of  the  pel  array  image  on  the  page.  Although  actual  page  dimensions  may  be  used 
allowing  for  the  raster  content  to  completely  fill  a  page  leaving  no  borders,  it  is  advised  that  the  assured 
reproduction  area  (ARA)  listed  in  table  1  be  used  wherever  feasible.  See  7.3  of  ISO  8613-2  for  general  rules 
for  positioning  pages  on  presentation  surfaces. 


6.3.3.3        Nominal  page  sizes 

The  nominal  page  sizes  that  may  be  specified  are  listed  in  table  1 .  in  i^cklSlon^  1 1  inch  rdi  p&p&r  <tf  mf^ 
length  is  supported.  These  may  be  specified  in  portrait  or  landscape  orientations.  All  valuoo  of  nominal 
pago  oizo  up  to  ANSI  E  cizo  arc  basic.  All  oizoo  larger  than  ANSI  E  oizo  and  roll  paper  arc  non  baoio  and 
thoir  uoo  in  a  document  muot  bo  indioatod  in  tho  dooumont  profile  uoing  the  Medium  typo  attribute  (Soo 


tabic  2).:: 

All  valu0$  Qi  non^r^l  pag$  $tzd  asre  noft-ba^c  iartd  hence  all  values  used  in  a  (jboument  mu^  b$ 

mdicatec 

i  m  the  ctocument  profJie  usir^  the 

"medium  type" 

attribute  |See  tabt&  Z). 

Any  of  the  nominal  page  sizes  defined  in  table  1 ,  subject  to  the  restriction  specified  above,  may  be  specified 
as  the  default  value  in  the  document  profile. 


Table  1  also  includes  the  recommended  aoourod  roproduotion  area  (ARA^.  Information  loss  may  occur  when 
a  document  is  reproduced  if  the  dimensions  of  the  CompositePage  exceed  the  ARA  for  the  specified 

nominal  page  size. 


6.3.4  ImageFrame 

An  ImageFrame  is  a  constituent  constraint  which  defines  a  lowest  level  frame  used  for  laying  out  the  image 
of  an  engineering  drawing,  illustration,  or  other  raster  scanned  image.  This  frame  contains  a  single 
SpecificBlocl<  containing  a  raster  graphics  content  portion.  Note  that  there  must  be  exactly  one 
ImageFrame  on  each  page  and  one  block  in  the  frame. 

The  frame  has  a  fixed  position  that  is  equal  to  the  origin  of  the  page.  The  vertical  and  horizontal  dimensions 
of  this  frame  are  fixed  and  equal  to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area 
of  the  page. 


6.3.5  SpecificBlock 

A  SpecificBlock  is  a  constituent  constraint  which  defines  a  basic  layout  object  used  to  position  and  image 
the  content  portions  associated  with  an  ImageFrame. 

The  position  of  the  block  is  fixed  and  defaults  to  the  origin  of  the  superior  frame.  The  dimensions  default 
to  the  maximum  size  that  can  be  achieved  for  the  position  within  the  area  of  the  superior  frame. 
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Table  1  -  Dimensions  for  various  page  sizes 


Page  type 

Size 

Size  (BMU) 

ARA  (BMU) 

-  Metric 

IS0-A5 

148mm  X  210mm 

7015  X  9920 

not  defined 

IS0-A4 

210mm  X  297mm 

9920  X  14030 

9240  X  13200 

IS0-A3 

297mm  x  420mm 

14030  X  19840 

13200  X  18480 

IS0-A2 

420mm  X  594mm 

19840  x  28060 

18898  X  27118 

IS0-A1 

594mm  x  841mm 

28060  x  39680 

26173  X  37843 

ISO-AO 

841mm  x  1189mm 

39680  X  56120 

37843  X  54283 

-  ANSI,  North  American  (NA) 

NA-A 

8.5in  X  Ilin 

10200  X  13200 

9240  X 12400 

NA-B 

Ilin  x  17in 

13200  X  20400 

12744  X  19656 

NA-C 

17in  X  22in 

20400  x  26400 

19500  X  25800 

NAD 

22in  X  34in 

26400  x  40800 

25800  X  39600 

NA-E 

34in  X  44in 

40800  x  52800 

39600  X  52200 

NA-F 

28in  X  40in 

33600  x  48000 

32400  X  47400 

NA-G 

1 1  in  X  90in 

13200  X 108000 

12400  X 106800 

NA-H 

28in  X  143in 

33600  X 171600 

31400  X  170400 

NA-J 

34in  X  176in 

40800  X  211200 

39600  X  210000 

NA-K 

40in  X  143in 

48000  X  171600 

47400  X  170400 

NA-Legal 

8.5in  X  14in 

10200  X  16800 

9240  X  15480 

-  Foldouts 

Small 

Ilin  X  14in 

13200  X  16800 

12744  X  15480 

NA-B 

Ilin  X  17in 

13200  X  20400 

12744  X  19656 

Legal 

2$7mm  x  364mm 

istui  X  iri$e 

mmmwm 

Letter 

162mm  x  2$7mm 

6$96x  12141 

mxixmm. 

Tutorial  Note  -  These  page  sizes  are  for  the  portrait  orientation. 
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Table  2  -  Layout  attributes 


Attributes 

Basic  values 

Default 
values 

Non-basic 
values 

Page  dimensions  ** 

CARA  NA  A  F, 
OAHA  NA  Legal, 
ISO  M  A1, 
Small  Foldout 
CARA^NAA* 

CARA  NA-A 

ARA  NA  Gi-K, 
ISO  A(M3,Jap«^ 

11"  Rolliiiiilpl 

Medium-type  ** 
(Nominal  page  size) 

NA  AF, 
NA  Legal, 
ISO  A^  A1, 
Small  Foldout 

NA  ai-K, 

ISO  AOAS, 
11"  <floll  PApea 

Tutorial  Note  -  See  table  1  ** 


6.4      Document  layout  characteristics 


This  DAP  provides  fef-only  |||lormatted  documents.  Hence,  no  provision  is  made  for  constraining  the 
document  layout  process  other  than  as  implied  in  the  formatted  documents  supported  by  this  DAP.  In 
particular,  these  formatted  documents  are  characterized  by  the  following: 

a)  Documents  containing  only  composite  pages; 

b)  Documents  may  contain  one  or  more  pages; 

c)  Pages  may  vary  by  orientation  within  a  document; 

d)  Each  page  contains  a  single  raster  graphics  content  portion  representing  the  image; 

e)  Content  is  positioned  within  fixed  position  and  dimension  frames. 


6.5      Content  layout  and  imaging  control 

A  document  is  modelled  as  an  image  represented  by  a  raster  graphics  content  portion,  as  specified  in  ISO 
8613-7. 

The  only  content  architecture  that  may  be  specified  using  the  attribute  iGiontent  architecture  classf  is 
formatted  processable  raster  graphics.  The  formatted  processable  raster  graphics  content  must  be  specified 
as  the  default  in  the  document  profile. 
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6.5.1 


Raster  graphics  content 


6.5.1.1 


Introduction 


This  clause  defines  the  features  that  are  applicable  to  the  raster  graphics  content. 
The  default  values  for  the  following  features  may  be  specified  in  the  document  profile: 

a)  type  of  coding  (required); 

b)  compression; 

c)  pel  path; 

d)  line  progression; 

e)  pel  spacing; 

f)  spacing  ratio; 

g)  clipping. 

The  specification  in  a  document  of  a  non-basic  feattH=e-|iijiiby  a  presentation  or  coding  attribute  must  be 
indicated  in  the  document  profile. 


6.5.1.2        Raster  graphics  content  architecture 

The  formatted  processable  raster  graphics  content  is  the  only  content  architecture  class  supported  by  this 
DAP  and  is  the  only  default  content  architecture  class  that  can  be  specified  in  the  document  profile. 

In  a  composite  page,  only  one  content  portion  can  be  associated  with  the  image. 


6.5.1.3        Raster  graphics  encoding  methods 

Throe  encoding  mothodo,  CCITT  T.6  (untiled),  Tiled,  and  Bitmap  arc  supported  by  thio  profile  ao  txtoio 
valuoG. — Neither  the  CCITT  T.4  one  dimonoional  method  nor  the  CCITT  T.4  two  dimensional  method  io 
oupported. 

The  CCITT  Rooommondation  T.6  Group  4  oomproooion  algorithm  shall  bo  used  in  all  oases,  tiled  and  untiled, 
oxoopt  whore  it  io  more  effioiont  to  retain  an  imago  or  tile  imago  in  bitnrtap  format  or  to  opooify  a  tile  ao  being 
cither  all  background  or  all  foreground. 

Tlw  <s»Ttert  msry  i»  «iDoded  in  acc«^ance  with  ^  «icodlr^  schemes  decried  In  CCITT 
R$OC»mEfri0fKtatlon^T,4  igitKi  Tj^  in  Ihe  od$0  of T.*,  ^^the  <3ift0-dlm:eri$loft$l  or  two-dijnension^  enc<xl1r^ 
sd»m&  may  be  ased*  Mm  the  bitmap  encoding  scheme  d^ined  ki  i$0  may  be  used.  AS  these 
lomi&  i}lt  enoodli^  m$iy  be  u$ed  in  4  $in0le  ciooi,tm$nt  ^nd  v^ue^.  Uncompressed'  mode  of 
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In  Q  content  portion,  It  Is  roqulrod  that  tho  Number  of  pole  per  lino  and  Number  of  linoo  paramotoro  of  tho 
Coding  attributeo  attributeo  bo  opoolfiod. — The  value  of  theoo  parametero  ohail  bo  a  pooltive  number. 
Otherwioe.  no  eonotrainto  are  placed  on  theoe  parametero  by  thio  profile.  icagaiiera::!^ 
tPisd     codmo  ^it!i^4te  "nunr^r    psite  per  [kvsT  b&  ^)eclfled<  The  coding  altribut^i^  ""msub^    I»i6s"  may 
ai$o  b0  r$$trlotion  l»  piacoct  m  Htmvtjitm  then  may    ^p^\05t  forthm  oodNiQ  ^t|i>(^. 

This  profile  places  no  constraints  on  the  size  of  the  pel  arrays  that  may  be  used  ao  long  ao  the  oize  doeo 
not  exceed  the  page  dimenoion  oizo. 

The  type  of  coding  method  used  is  specified  by  the  attribute  p-type  of  coding.  The  use  of  this  attribute  is 
mandatory  in  the  fDdocument  architecture  default^  of  the  document  profile  to  define  the  default  value  of 
either  |T.6  encoding!  (untiled)^  ^tnoodln^  -  MSB*  (untiled),  or  lulled  encoding|  The  use  of  this  attribute 
in  the  description  of  the  content  portions  is  non-mandatory.  If  this  attribute  is  not  specified  for  a  particular 
content  portion,  then  the  default  value  specified  in  the  |D|ocument  architecture  defaults?  of  the  document 
profile  is  used. 

If  the  ^iled  encoding  method  is  used,  the  default  value  of  512  for  the  |M|umber  of  pels  per  tile  lin^  and 
^Niumber  of  lines  per  tlM  must  be  used.  No  other  values  are  supported,  therefore  these  two  attributes  do 
not  need  to  be  specified.  If  the  ?>Rile  types^  attribute  is  not  present,  then  all  tiles  will  be  T.6  encoded.  If  it 
is  present,  then  there  must  be  a  value  specified  for  each  tile  in  which  case  only  'null  background^,  |null 
foreground*,  |T.6  encoded',  X6  encodal  ♦  M$&\  or  'bitmap  encoded?  values  are  supported.  iiiiT.4  one 
dimenoional  and  T.4  two  dimenoionai  encodings  are  not  supported,  there  are  no  restrictions  bri  the  use 
of  the  pliling  offset^  attribute  other  than  that  specified  in  ISO  8613-7  Addendum. 

See  table  D.I,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.5.1.4        Raster  presentation 

Raster  presentation  is  controlled  by  the  presentation  attributes  specified  in  ISO  8613-7.  This  DAP  provides 
for  additional  constraints  on  these  presentation  attributes  as  specified  below. 

The  basic  values  for  Ihe  attilbule  ""Ppel  path^  vatues-supported  by  this  profile  are  0  and  90  degrees.  The 
|P|el  path?  values  of  180  and  270  degrees  are  non-basic. 

The  basic  vaU($iSi  fi:;^thfi^€^ibut«  "Mine  progression*  vakie-supported  by  this  profile  is  270  degrees.  The 
mine  progressior^  value  of  90  degrees  is  non-basic. 

The  basic  Pel  spacing  values  supported  by  this  profile  are  the  ratioo  equal  to  6  and  4  BMUs  between 
adjacent  pels. — This  oorreopondo  to  equivalent  rooolutiono  of  200  and  300  pels  per  26.4  mm  (1  in.), 
reopootively  when  tho  BMU  io  interpreted  ao  1  /1 200  inch.  Values  for  Pel  opaoing  other  than  theoe  ratioo  are 
non  baoie,  i.e.,  6,  3,  2,  and  1  BMU.  These  eorreopond  to  equivalent  reoolutionG  of  240,  400,  600,  and  1200 
polo  per  26.4  mm  (1  in.). 

Ar^  value  rriay  be  expllc^  speciled  for  pet  spacing  provlc^  ^  Itm  ^clngi  b&tmm  peis  is  rtdi;  less  lhan 
1  BMU  th0  psH  !&pa(^ng  tmd  rtoi  be  an  Integer  vaiu$.  th^  ol  *rtu8'  may  not  ^}$cifkd  beoau$$ 
tfte  scalable  layout  px>cess  Is  not  si^sported  Ttie  specHlDa^  of  tiie  spacing  of  16, 12,  6^  6«  4  3,  2. 
^  1  BMU  b^^t^n  ^faoant  pel$     ba$io^  1^  ^paeifloatiofi  of     otNr  ^paoltm  h  »ort-ba$io  and  mm 
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be  $peoleci  tn  the  document  pt<M$^ 

iiiii 


%  The  baski  pel  spadle^  va&te&  listed  sbaum  ^«  equivalent  to  resolutions  of  7S,  100, 150, 200, 240, 300.  4O0| 
eoo,  ««i  1200  |«>l6  per  25.4mm  «$p«oth«)y  ^i«>»n  tiw  Bm  k  Interpret  m  y^ZQOtfK^^ 


Th9  iKt(%>ute 

nfif  :^pecili$6  two  Inte^we.  the  rirtio  of  which  d^wti6w»  the     spacing.  No 

m 

values  of  ihcistf 

There  are  no  restrictions  on  the  use  of  the  sGolipping?!  attribute.  The  ||mage  dimensions!  attribute  is  not 
supported. 

There  are  no  restrictions  placed  on  the  value  of  the  fSlpacing  ratio"  attdbUle  providing  that  the  resultant  line 
spacing  is  not  less  than  1  BMU.  Also,  the  line  spacing  need  not  be  an  integral  number  of  BMUs.  Ail  values 
are  basic. 

See  table  D.2,  Annex  D,  for  a  tabulated  list  of  the  attributes  and  their  basic,  default,  and  non-basic  values. 


6.6      Miscellaneous  features 

Specification  of  the  attribute  "application  comments"  is  optional.  When  used  in  conjunction  with  the  iTfype 
of  codingi  of  'Tfiied  encodiilg',  it  contains  a  sequence  of  positive  integers,  one  for  each  tile  in  the  content 
portion.  The  sequence  of  integers  is  a  set  of  indices  representing  the  octet  offsets  to  the  beginning  of  the 
respective  tiles,  starting  from  the  beginning  of  the  "content  information".  A  tile  index  of  zero(0)  indicates  that 
the  respective  tile  is  null.  The  integers  will  be  sequenced  in  the  same  order  as  the  tiles.  The  tiles  will  be 
sequenced  primarily  in  the  Pj|el  path  and  secondarily  in  the  Mine  progression  direction  as  defined  by  the 
presentation  attributes. 


6.7      Document  management  features 

Every  document  interchanged  in  accordance  with  this  DAP  must  include  a  document  profile  containing 
information  which  relates  to  the  document  as  a  whole. 

The  features  specified  by  the  document  profile  are  listed  below.  A  definition  of  the  information  contained 
in  these  features  is  given  in  the  corresponding  attribute  definitions  in  ISO  8613-4. 

Document  constituent  information: 

a)  specific  layout  structure; 

b)  presentation  styles  (optional). 
Document  characteristics: 

a)  document  application  profile; 
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b)  document  application  profile  defaults; 

c)  document  architecture  class; 

d)  content  architecture  class; 

e)  Interchange  format  class; 

f)  ODA  version  date; 

g)  raster  graphics  content  defaults. 
Non-tsasic  document  characteristics: 

a)  page  dimensions; 

b)  medium  type; 

c)  raster  graphics  presentation  features. 
Document  management  attributes: 

a)  document  description  (only  document  reference  supported). 
The  attributes  applicable  to  the  document  profile  are  defined  in  table  D.3,  Annex  D. 

7     Specification  of  constituent  constraints 
7.1      Document  profile  constraints 
7.1.1       Macro  definitions 

--  General  macros  ~ 
DEFINE(FDA,  "{'formatted'}") 

DEFINE(DAC,  "DocumentProfile  (Document-architecture-class)") 

DEFINE(FPR,"ASN.1{2  8  2  7  2}")  ~  Raster  formatted  processable  ~ 

-  Basic  page  dimensions.  ~ 
DEFI N  E  (BasicPageDimension," 

-fREQ  #hori2ontal-dimension  {REQ  #fixed-dimension  {  <  -  40800  l»9240  }}, 
REQ  #vertical-dimension  {REQ  #fixed-dimension  {  <  -6g800t.1g400  }}]■ 

 Any  oizo  equal  to  or  omallor  than  the  actual  page  oizo  of  ISO  A1  and  ANSI  E  portrait. — 

I  iREQ  # horizontal-dimension  {REQ  #fixed-dimension  {  < -62800  t.1jS!40Q  }}, 
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REQ  #vertical-dimension  {REQ  #fixed-dimenslon  {  <  - <10800  t  }}f 

 Any  oizo  oqual  to  or  omallor  than  tho  aotual  pqgo  olno  of  ISO  A1  and  AM8I  E  landooopo — 

") 

-  Any  s«e«qiMi  to  or  smaller  than  CARA  (Common  Assured  Reproduction  Area)  onSO  t^^'W^^ 
PomafeaiKll^$oapemay  l)e$pec8ie(i.  ' 

--  Non-basic  page  dimensions.  - 
DERNE(NonBaQioPagoDimonoiono," 

[REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  [40801  ■  '18000)], 
REQ  #vortioal  dimonoion  [REQ  #fixod  dimonoion  [62801  .21 1200]]) 

 Any  oizo  larger  tlian  tho  rango  of  baoio  valuoo  in  ANSI  E  portrait  and  oqual  to  or  omallor  than  tho 

full  oizo  of  ANSI  K  portrait. — 

I  [REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  [62801. .311 200) ), 
REQ  #vortioal  dimonoion  [REQ  #fixod  dimonoion  [40801..<18000])] 

 Any  oizo  larger  than  tho  rango  of  baoio  valuoc  In  ANSI  E  landooapo  and  oqual  to  or  omallor  than 

tho  full  oizo  of  ANSI  K  landooapo. — 

I  [REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  [13200]]. 

REQ  #vortioal  dimonoion  [REQ  Vfixod  dimonoion  [>  -  16801])] 

 Any  portrait  oizo  larger  than  tho  typioal  foldout  oizo  (11  in  x  1 4  in)  including  1 1  inoh  roll  papor. 

I  [REQ  #horizontal  dimonoion  [REQ  #fixod  dimonoion  [>  -  16801]], 
REQ  #vortioal  dimonoion  [REQ  #fixod  dimonoion  [13200]  ]] 

— Any  landooapo  oizo  larger  than  tho  typioal  foldout  oizo  (14  in  x  1 1  in)  including  1 1  inoh  roll  papor 

D£FINE(|Sk»i6s^toPageD{meii^bn^*' 

{l)EQ  #liori2on£$l'<8mer}$lon  {BEQ  #^eci-<fime»$lDn  {1,.396@Q}'}, 
^EO  #yertlcal^mB»8lon  {R£0  ^ixed^lmenslon  {ia401.«56iaOH> 
I  {I^EO  #liQ{^ontal-dir»en$ion  {R£0  #^ed-<fime»slQn  {$24t..i^9@80>}', 
REO  #vertical^men$ion  {REO  #(lxed^menslon  {1.>66iaO»]' 

-  Up  to  l$Q  AO  portrait  - 
I  {fUEO  #tiorizortal^mension  {REO  #llxed^n)ensiDn  {1^>66120>}^ 
REO  #vertioal^ln!ien$lo»  {REQ  #ilxecl-dlmen$iQn  {d24t„396ao»} 
:|  {RED  #liorizomal^menslon  {REQ  #fixedK«menslon  {12401x^561 20}}* 
^EO  #vertloal'CBmen$lo»  {REQ  ij^ed-cHmension  {i..396@0B> 

^  up  to  ISO  AO  landscape 
I  {REQ  #ho£lzor^<Smer}slon  {REQ  #{iKed<Umension  {t..4aQQQ>}, 
REO  #v^lcal-tllmenslon  {RED  idxed-cUrEwnslon  {ia4ai«21ia00}}} 
I  |REQ  #lior3zontal<<)lme»$lon  {REQ  #lbteci'<llmen$io»  {924t.,4aQ0O|>, 
REQ  #veftlGal^menslon  {REQ  #fix8d*<jlmenslon  {1xjat1200»} 

-Mp  10  ANSI  *|/K  portrait  ~ 
I  {REO  #|}orizomal*<JlmBn8lon  {REQ  #f8cedHj4menslon  {1xjai1200}>, 
REQ  #v$rtioa)'<Smension  {REQ  #fb£ed-cQmen$iQn  {$24i..4aQQQ}» 
i  {REQ  #tiorizortalHilmeRslon  {REO  #«xed-ElJmension  {ia4O1«^iia0O}>, 
ItEO  #vertloal'<)lmen$lo»  {REQ  #lked'<ilmen$iQn  {i..4a0OQH> 

«  «p to ANSIJ^ landscape 
I  |Rea  #fiorizor«al-<MmettslO)i  {REQ  #8}{aci'<llmet^slo»  {1..12141», 
REQ  ^vertlcal^dlmenslon  {REQ  #f«ed^<mension  {12401xJ7196}>> 
I  {REQ  #hoi^2orital-cPmen$lon  {REQ  #ex$d-cfimenslon  {a24t.J2t4f }>, 
REQ  #vertical-£flmenslon  {F^Q  #8xed-ctlmens«on  {1«1719©»1 

-tip  to  Japanese  legal  portrait  ~ 
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REQ  #vertlcal^finienslpn  {REO  #«xed^raenslo«  {l«12141H} 

,         '^^^  ^'^^  ical  foldc  14  in)  Includma  11       rnB  n«n«r 

RE0#veftlc8lKflmer  j^^jj, 

~  ^Yhm^p^^^i^gm^mtypk^mm^iU fei x  11  Ir^ 6iclu<««g ii  inch 


REQ  #veftlcal-d}menslo«  {REQ  #lixed^llmensloo  {Umim}} 

~«p  10 1$0  AO  portrait  ~ 
I  {REQ  #rior«<jrtal^dimenslon  {REO  #«Ked<8merjslon  {1«66ia<}». 
REO  #vortl(^l-<«f¥j$ftslc»j  {REQ  #ik^^lm6n$loft  ^1.,39680}n 
f  - .  up  to  ISO  AO  landscape  - 

REQ  #vertical^'mensi(»?  {REQ  #liX€K(^lm©nslo«  f1> Jttiaooni 

-upl0AN$i4/Kpor^ft  ~ 
iJS^^  #horfeomal^m©n8loB  {REQ  #fs{«c(Kfimen8lo«  {i.Mimn. 
REa  #v^lc^^mefislon  {REQ  #«x^<Bm0rjslon  {l,.48DO0m 
t  *  -  «P  to  ANSI  J/K  landscape - 

I  {REO  #liotfeoraal^merj$lott  {REQ  #R>e^<lir«ier«lofi  {i,J2i4iB 
REQ  #vertlcal<tlreeBsioti  {REQ  #8xedHaimenslon  iUi7m}}} 
t  -tip to 4apafteset$g$i portrait  ~ 

LS!r^  #tjor«or*al<OmeRsion  {REQ  #«xed-dirpenslon  {t>17196>L 
REQ  #v$rtlcal'<«m0ft§lorj  {REQ  m^d^tmnsitm  {I.J2141 }}} 
^  -     to  Japanese  legal  landscape  « 

DEFINE(NominalPageSizes," 

--  ISO  Page  Sizes  - 

4REQ  #iiorizontal-dimension  {7015},  REQ  #vertlcal-dlmension  {9920} 

--  ISO  A5  Portrait -- }- 
I  -fREQ  #horizontal-dimension  {9920},  REQ  #vertical-dimension  {7015} 

--  ISO  A5  Landscape  } 
I  -fREQ  #horizontal-dlmension  {9920},  REQ  #vertical-dimension  {14030} 

-  ISO  A4  Portrait -- ^ 

I  -fREQ  #horizontal-dimension  {14030},  REQ  #vertical-dimension  {9920} 

--  ISO  A4  Undscape -- f 
I  -fREQ  #horizontal-dimension  {14030}.  REQ  #vertjcal-dimension  {198430} 

--  ISO  A3  Portrait  -  }- 
I  -fREQ  #horizontal-dimension  {198430}.  REQ  #vertlcal-dimension  {14030} 

-  ISO  A3  Undscape  -  }- 
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■fREQ  #horizontal-dimension  {198430},  REQ  #vertical-dimension  {280630} 

-  ISO  A2  Portrait  --  f 
4REQ  #horlzontal-dimension  {280630},  REQ  #vertical-dimension  {198430} 

--  ISO  A2  Landscape  -  f 
■fREQ  #horizontal-dimension  {280630},  REQ  #vertical-dimension  {3973^90} 

--  ISO  A1  Portrait  --  f 
-fREQ  #horizontal-dimenslon  {39732|§|},  REQ  #vertical-dimension  {28063|} 

-  ISO  A1  Landscape  -  f 
-fREQ  #horizontal-dlmenslon  {3973Si80}.  REQ  #vertical-dimension  {564^l||!} 

-  ISO  AO  Portrait  --  ]■ 
4REQ  #horlzontal-dimenslon  {56473129}.  REQ  #vertical-dimension  {39732680} 

-  ISO  AO  Landscape  - 1 

-  ANSI  Page  Sizes  - 


-fREQ  #liorizontal-dimenslon  {10200},  REQ  #verticai-dimension  {13200} 

-  ANSI  A  Portrait  -- 1 

•fREQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {10200} 

--  ANSI  A  Landscape  -  ]■ 
4REQ  #horizontal-dimension  {10200},  REQ  #vertical-dimension  {16800} 

-  ANSI  Legal  Portrait  -- 1 

4REQ  #horizontal-dimension  {16800},  REQ  #vertical-dimension  {10200} 

-  ANSI  Legal  Landscape  --  ]■ 

-fREQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {20400} 

--  ANSI  B  Portrait  ^- 
iREQ  #horizontal-dimension  {20400},  REQ  #vertical-dimension  {13200} 

--  ANSI  B  Landscape  -  ]■ 
fREQ  #horizontal-dimension  {20400},  REQ  #vertical-dimension  {26400} 

--  ANSI  0  Portrait  f 
fREQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension  {20400} 

-  ANSI  0  Landscape  -  f 

•fREQ  #horizontal-dimension  {26400},  REQ  #vertical-dimension  {40800} 

-  ANSI  D  Portrait  -  f 

fREQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {26400} 

-  ANSI  D  Landscape  -  f 

fREQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {52800} 

-  ANSI  E  Portrait  --  f 

fREQ  #horizontal-dimension  {52800},  REQ  #vertical-dimension  {40800} 

-  ANSI  E  Landscape  -  f 

fREQ  #horizontal-dimension  {33600},  REQ  #vertical-dimension  {48000} 

-  ANSI  F  Portrait  -  f 

fREQ  #horizontal-dimension  {48000},  REQ  #vertical-dimension  {33600} 

-  ANSI  F  Landscape  f 

fREQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {108000} 

--  ANSI  G  Portrait  --  f 
fREQ  #horizontal-dimension  {108000},  REQ  #vertical-dimension  {13200} 

-  ANSI  G  Landscape  --  f 

fREQ  #horizontal-dimension  {33600},  REQ  #vertical-dimension  {171600} 
ANSI  H  Portrait  --  f 
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I  iREQ  #horl2ontal-dimension  {171600},  REQ  #vertical-dimension  {33600} 

--  ANSI  H  Landscape  --  f 
I  iREQ  #horizontal-dimension  {40800},  REQ  #vertical-dimension  {211200} 

--  ANSI  J  Portrait  --  ^- 
I  -fREQ  #horizontal-dlmenslon  {211200},  REQ  #vertlcal-dlmenslon  {40800} 

-  ANSI  J  Landscape  -  } 

I  -fREQ  #horlzontal-dlmenslon  {48000},  REQ  #vertical-dlmension  {171600} 

-  ANSI  K  Portrait  --  f 

I  -{-REQ  #hori2ontal-dlmenslon  {171600},  REQ  #vertical-dimension  {48000} 

-  ANSI  K  Landscape  -  ^- 

-  Fddouts  - 

I  ^REQ  #horizontal-dimension  {13200},  REQ  #vertlcal-dimension  {16800} 

Foldout  Portrait  -  f 
I  -fREQ  #horizontal-dimension  {16800},  REQ  #vertical-dimension  {13200} 

Foldout  Landscape  --  f 
I  iREQ  #horizontal-dimension  {13200},  REQ  #vertical-dimension  {>=  16801} 
--  Any  portrait  size  larger  than  the  typical  foldout  size  (11  in  x  14  in)  including  11  inch  roil  paper  - 
I  4REQ  #horizontal-dimension  {>=  16801},  REQ  #vertical-dimension  {13200} 
-  Any  landscape  size  larger  than  the  typical  foldout  size  (14  in  x  11  in)  including  11  inch  roll  paper  - 


7.1 .2       Constituent  constraints 


7.1.2.1  DocumentProfile 

{ 

-  Presence  of  document  constituents  - 

REQ  Specific-layout-structure  {'present'}, 
PERM   Presentation-styles  {'present'}, 

~  Document  characteristics  - 

REQ     Document-application-profile    {--  See  clause  8  for  a  definition  of  the  permitted  values  for 

this  attribute.  -}, 

REQ     Document-application-profile-defaults  { 

~  Document  architecture  defaults  ~ 

REQ    #content-architecture-class  {$FPR}, 

PERM  #dimensions  {$BaoioPagoDimonoiono  | 

$NonBaGioPagoDimonoionG$Fermiss(blePageC^mensioo8}, 
PERM  #medium-type  { 
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PERM  #nominal-page-slze 
PERM  #side-of-sheet 


{$NominalPageSi2es}, 
{ANYVALUE}}. 


REQ 
REQ 
REQ 


REQ 


-  Any  permitted  medium  type.  Both  landscape  and  portrait  may  be  specified.  - 

REQ    #type-of-coding  {ASN.1  {2  8  3  7  0}  -  T6  encoding  -- 

I  ASN.1  {283  75}--  tiled  encoding  - 
i  Ami(2  83  76}     T6  erKxxJing  -  MSB  -  }. 
PERM  #page-positlon  {ANY  VALUE}. 

PERM  raster-graphics-contents-defaults  { 

PERM  #pel-path  {ANY  VALUE}, 

#llne-progresslon  {ANYVALUE}. 
#pel-spacing  {REQ  #length  {&+4ANY  WmM}, 

REQ  #pel-spaces  {+ANY~VALUE}}, 

PERM  #spacing-ratio 

{REQ  #line-spacing-value       {ANY  VALUE}. 
REQ  #pel-spacing-value  {ANY_VALUE}}, 
PERM  #compression  {'oomprcoood'  |  'unoomproGood'ANY  .VAUJE}, 

PERM  #clipping  {ANY_VALUE}}. 


PERM 
PERM 


Document-architecture-class 
Content-architecture-classes 
Interchange-format-class 


ODA-version 

{REQ  #standard-or-recommendation 
REQ  #publication-date 


{$FDA}. 
{$FPR}. 

{--  This  attribute  required  only  kx  ODIF 
irfterchange.  See  clause  8  for  a  definition  of  the 
permitted  values  for  this  attribute.  --}, 


{'ISO  8613'}, 

{ '1080  07  0119914^31 ' }  }, 

-  tt^      fi^>reseftt$  the  tl^tfe  ^  thl&  dap  was  approved.  This  Is  the  of^y 
aps'oved  value,  however,  the  dale  will  be  changed  If  the  DAP  Is  significantty 

-  r<eivi$e4  ii  die       1^  f$N%9d,  U$e  of  l^e  new  date  is  required  only  when  th«| 

t!t  addllorial  furi(^r»llty  is  belrtg  used.  Thai  legacy  produces  way  <sx^mm  Ha 
"  «L^:^K)tt  ^  DAP, 


Non-basic  document  characteristics 


PERM  Page-dimensions  {PMUL  {$NonBaslcPageDimensions}}, 

PERM  Medium-types  {PMUL{ 

PERM    #nominal-page-size  {$NominalPageSizes}, 

PERM   #side-of-sheet  {ANYVALUE}}}, 

-  M  v^Me»  <if  ''firtecQi^  type**  ^re  non-bi^  - 
?wm  Cocllng*atiraa*es  { 

R£Q  #rd^'0rdph2o$^odlfig-dttrtbutes 

REQ  jJfcompressjofi  {'unccanpressed'}}}, 


PERM  Presentation-features  { 

PERM  #Raster-graphics-presentation-features 
PWytl  PERM  #pel-path 


{  MUL  f 

{'180-degrees'  | 
'270-degrees'}T 
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PERM  #line-progression 
^A^iiiiii  #pel-spacing 


PMI^IiPilll  #spacing-ratio 

{REQ  #line-spacing-value 

REQ  #pel-spacing-value 


{'90-degrees'}- 

{REQ  #length  {ANY_VAtAJE} 

EXCEPT€T4{16,12,a,6^A3,2!.t }. 
REQ  #pel-spaces  {ANY_VAliE} 
EXCEPT 
i1}}T 


{ANY_VAyjE>  EXCEPT 


{ANY  VALUE}  EXCEPT 

in}}}>. 


--  Document  management  attributes  - 
-  Document  description  ~ 

REQ  Document-reference  {ANY_VALUE} 

} 

7.2      Logical  constituent  constraints 

No  logical  constituents  applicable  in  this  clause. 


7.3      Layout  constituent  constraints 


7.3.1       Macro  definitions 

DEFINE(RAST;  CONTENTJD_OF(RASTeRRa$ter*^^^&«or«fi«tiX««on)") 


7.3.2       Factor  constraints 

FACTORt  ANY-LAYOUT  { 

SPECIFIC: 

PERM  Object-type  {VIRTUAL}, 

REQ     Object-identifier  {ANYVALUE}, 

PERM  Subordinates  {VIRTUAL}, 

PERM  User-visible-name  {ANY  VALUE}, 

PERM  User-readable-comments  {ANY_VALUE}t 
} 
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7.3.3.1 


Documentl^youtRoot 


DocumentLayoutRoot: 

SPECIFIC: 

REQ  Object-type 

REQ  Subordinates 

} 


ANY-LAYOUT  { 


{  'document-layout-root'}, 
{SUBJD_OF(ConnpositePage)  +  } 


7.3.3.2 


CompositePage 


CompositePage: 

SPECIFIC: 
REQ  Object-type 
REQ  Subordinates 
PERM  Dimensions 


ANY-LAYOUT  { 


PERM  Page-position 

PERM  Medium-type 

PERM  Application-comments 
} 


{'oompocito  page'}, 
{SUB_ID_OF(lmageFrame)}. 
{REQ  #hori2ontal  dimonoion 

[REQ  #fixod  dimonoion  [SBaoicPagoDimonoions 

I  SNonBaoioPagoDimonoiono]  ] , 
REQ  #vortioal  dimonoion 

[REQ  #fixod  dimension  ($Ba6ioPagoDimonGlonG 
SNonBaoioPagoDimonoiono) 


{ANYVALUE}, 

{PERM  #nominal-page-size  {$NominalPageSizes}, 
PERM  #side-of-sheet  {ANY  VALUE}}, 
{ANY  VALUE} 


7.3.3.3  ImageFrame 

ImageFrame:  ANY-LAYOUT  { 


SPECIFIC: 

REQ  Object-type 

REQ  Subordinates 

PERM  Application-comments 

} 


{'frame'}, 

{  SUBJ  D_OF(Specif  icBlock) } , 
{ANY_VALUE} 


7.3.3.4  SpeclficBlocl( 

SpecificBlockf 

SPECIFIC: 

REQ  Object-type 


{'block'}, 
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REQ  Object-identifier 
REQ  Content-portions 


PERI^ 
PERM 
PERM 
PERM 

PERM 

PERM 


} 


Content-architecture-class 
User-readable-comments 
User-visible-name 
Application-comments 

Presentation-style 

-  PStyle  for  raster  content 
Presentation-attributes 
PERM  #raster-graphics-attributes 
PERM  #pel-path 
PERM  #line-progression 
PERM  #pol  opaoing 


PWBM  #pi^spacin9 
PERM  #spacing-ratio 
PERM  #clipping 


{ANY_VALUE}. 
{$RAST}, 

mo  #{iorizor^ii3D^lon  {ANY  VAiilE}. 
{REO  mti^\mt\$km{Am  VALUE»>, 

{$FPR}, 

{ANYSTRING}, 

{ANYSTRING}, 

{ANYVALUE}. 

~  See  8.1.3  and  8.2.3  ~ 

{STYLE  ID  OF(PStyle)}, 


{ 


{ 


{ANYVALUE}. 
{ANY_VALUE}, 
[ANY  VALUE], 

{REQ'"#fengtt?  {mfVMJaEh 
mo  #pel-space$  {AKY„VALUE». 
{REQ  #line-spacing-value  {ANY_VALUE}, 
REQ  # pel-spacing-value  {ANY_VALUE}}, 
{ANY  VALUE}}} 


7.4  Layout  style  constraints 

No  layout  style  constraints  applicable  in  this  clause. 

7.5  Presentation  style  constraints 


7.5.1       Macro  definitions 

No  macro  definitions  are  applicable  to  this  clause. 


7.5.2       Factor  constraints 

FACTOR^         ANY-PRESENTATION-STYLE  { 

REQ     Presentation-style-identifier  {ANY_VALUE}, 

PERM  User-readable-comments  {ANY_STRING}, 

PERM  User-visible-name  {ANY_STRING} 
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} 


7.5.3       Presentation  style  constituent  constraint 


7.5.3.1  PStyle 

PStyle:  ANY-PRESENTATION-STYLE  { 

-  This  style  is  used  for  raster  grapiiics  content  - 

PERM  Presentation-attributes  { 
PERM  #raster-graphics-attributes  { 

PERM  #pel-path  {ANY  VALUE}, 

PERM  #line-progression  {ANY_VALUE}, 
PERM  #pel-spacing  {REQ  #length  {ANY_VALUE}, 

REQ  #pel-spaces  {ANY_VALUE}}, 
PERM  #spacing-ratio  {REQ  #line-spacing-value  {ANY  VALUE}, 

REQ  #pel-spacing-value  {ANY_VALUE}}, 
PERM  #clipping  {ANY_VALUE}}} 

} 

7.6      Content  portion  constraints 


7.6.1       Macro  definitions 

DEFINECTILED,"  ASN.1  {2  8  3  7  5}")  -  Tiled  raster  encoding  - 


7.6.2       Factor  constraints 

No  factor  constraints  are  applicable  to  this  clause. 


7.6.3       Content  portion  ConstKuenl  constraints 


7.6.3.1        Raster  graphics  content  portion 

Raster-graphics-content-portiorn  { 

REQ     Content-identifier-layout  {CONTENT  ID  OF(RASTER)ANYJ^/UaJ€}. 

mm  Tvi>8-Qr-codlng  {  A8N.H2 as 70>  *-T,6 encoding^ 

j  A$N.1i2  83  71}  -  T.4  one  dimensional  <^ 
f  i5ASN>  I  {2  8  5  7  2|  *•*  T.4  two  dImenslonaJ 
I  A$NJ{a  03  73}  "  bitmap  encoding  ^ 
I  ASMJ{2  a  3  7  S}  -  tBed  encoding 
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1  ASN.1<2 

8 

3 

7e>  ' 

MSB- 

i  ASN.1{a 

e 

3 

7  7}  -T.4i 

1  A$N.l|2 

3 

7e>  ^ 

-T.41 

■  MSB 

PERM  CcxJing-attributes 

REO  #f8Ster-grapNc$<:od^g^anr8}ties 
PERM  e#@ompression 
ReQPER*^  N#Jlumber-of-lines 
REQ  Ngfuumber-of-pels-per-line 
PERM  Typo  of  ooding  


{ 
{ 

{ANYVALUE}, 
{>0}, 

{>0}. 


[ASN.1[a83  70]  T.6  onooding 


|ASN.1[a83  73) 
ASN.1  [283  76] 


CASE  Raster-graphics-content-portion  (Type-of-coding)  OF  { 


bitmap  onooding — 
tiled  onooding — }t 


pTILE[J|:       |PERM  N#^1umber-of-pels-pe^tile-line 

PERM  N#fiumber-of-lines-per-tile 

PERM  T#tiling-offset 

PERM  T#tile-types 


PERM  Alternative-representation 
PERM  Content-information 
} 


{ANY_STRING}. 
{RASTER} 


{512}, 
{512}. 

{ANY_VALUE}, 
{'null  background'  | 
'null  foreground'  | 
'T.6  encoded'  | 
'bitmap  encoded'sj:: 
T6  encoded  *M$B1}}}. 


7.7      Additional  usage  constraints 

No  other  usage  constraints  are  currently  defined. 


8     Interchange  format 

Two  interchange  formats  are  supported  by  this  profile.  The  linterchange  Rformat  ODlF  {Gclass  A|:  can  be 
used  by  applications  requiring  a  binary  encoding  based  on  ASN.1.  The  Interchange  Format  SDIF  can  be 
used  by  applications  requiring  a  SGML  based  clear  text  encoding.  This  latter  interchange  format  is  an  SGML 
application,  called  Office  Document  Language  (ODL).  For  the  purposes  of  interchange,  the  ODL  ENTITIES 
are  placed  in  an  ASN.1  wrapper,  as  defined  by  SDIF.  Each  encoding  form  has  inherent  advantages. 
Conversion  of  document  encoded  in  one  interchange  format  into  the  other  should  not  produce  the  loss  of 
semantic  document  information. 
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8.1      Interchange  format  OOW  (class  A| 


8.1.1       Interchange  format 

The  value  of  the  document  profile  attribute  "interchange  format"  for  this  interchange  format  is  If-a".  This  fomn 
of  ODIF  Is  defined  in  ISO  8613-5. 

The  encoding  Is  In  accordance  with  the  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.1), 
as  defined  in  ISO  8825. 


8.1.2       DAP  identifier 

The  value  for  the  document  profile  attribute  "a|ocument  application  profile"  for  this  interchange  format  is 
represented  by  the  following  object  identifier. 

Editor*6  Note — To  be  supplied. 


8.1.3       Encoding  of  appiication  comments 

ISO  8613-5  define  the  encoding  of  the  attribute  ^!A|pplication  G|omments*  as  an  octet  string.  For 
SpecificBlock,  this  DAP  requires  that  the  encoding  withiin  that  octet  string  be  in  accordance  with  the  ASN.1 
syntax  specified  in  the  following  module  definition. 

Ml  STiDAPSpecif  ication 

DEFINITION!  ::=  BEGIN 

EXPORTS  Object-Appl-Comm-Encoding; 

Object-Appl-Comm-Encoding  ::=  SEQUENCE  OF  INTEGER 
END 


8.2      Interchange  format  SDIF 


8.2.1       Interchange  format 

The  document  profile  attribute  "interchange  format"  does  not  apply  for  this  interchange  format.  The  SDIF 
encoding  of  ODA  is  defined  in  Annex  E  of  ISO  8613-5.  In  addition,  ISO  8613-6r-7,  and  8  contair|  additional 
specifications  for  this  encoding  of  ODA. 
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8.2.2       DAP  identifier 

The  value  for  this  attribute  "Dilocument  application  profile"  for  this  interchange  format  is  represented  by  the 
following  object  identifier. 

Editor's  Noto   To  bo  cuppliod. 

iso     ldentiecN}rgsfizatiafi  {3|  oiw  (14)  ociasl9  (II >  ^ge^ppi  (t)  ras^^-^^sdlS  (2) 


8.2.3       Encoding  of  application  comments 

For  SpecificBlock,  the  encoding  of  the  attribute  "Aiipplication  comments"  is  defined  in  a  data  stream 
conforming  to  this  profile  with  the  following  DTD  definition: 

<!DOCTYPE  odaac  [ 

<!DOCTYPE — doe — PUBLIC — "  //USA  OIW//SGML — ENCODED — OOA — APPLICATION 
COMMENTS//EN"> — 

<! ELEMENT  objappo  O  (#PCDATA)> 

■<A — Object  applioation  comment — > 

}^ 

<W  Hie  following  sel  <3f  d@c^a(iE^lohs  tmy  be  Invoked  1^  m\nQ  a  fuUio  entity  as  ^€Momi 
<IDOOTVPEocfeac  Public  V/USA<«W//DTD$<3MLENC^INC»0PA  APPyC^TlON<X5li^Em 

<i-  NOH:  To  pdr$$  th^  ioSowIn^  Dooumont  Type  D0ol9mtlQ»  8iib$0t,  fjtace  th^  Dooum^nft  Typ^ 
dedaratloR*  <IDOCTYP£  odaac  T    the  beg&wing  of  t\m  fie  and  1>"  al  the  ©wJ  of     fie.  -> 

<IELEjMI0^  odaac » *  ((^Jlapp})^  > 

<l^>^  Objet^  epi^lcatlcK^  conmnent  ^> 
<  lELEMEHT  Qb^ppO  -  O  (#Pa3ATA)> 

8.3      Encoding  of  raster  content  information 

The  encoding  of  raster  content  information  In  the  bitmap  encoding  scheme  is  that  specified  in  9.3  of  the 
raster  graphics  content  architecture  part  of  ISO  8613-7,  that  is,  the  first  pel  in  the  order  of  bits  Is  allocated 
to  the  most  significant  bit  of  an  octet.  The  encoding  of  the  code  words  in  the  Group  4  faooimilo  encoding 
sohomo  is  such  that  the  first  or  only  bit  of  the  firot  code  word  shall  be  plaood  in  the  least  significant  bit  of 
the  first  octet.  Subsequent  bits  of  the  first  and  following  code  words  arc  placed  in  the  dirootion  of  more 
oignifioant  bite  in  the  firot  and  following  octcto.  lim  encoding  of  the  code  words  in  the  €CnT 
Be&ofm^mmim  lA  enoodltJ^  ^eme$  mi  be  <tone  le  ^her  the  tip  or  tlewi  m  0f4&t.  The  m 
order  h  specified  by  theaMuies  "type  of  cocBn^  or'^ile  types".  Th3  j^^t»ile  '^types^  Is  used  only^n 


the  value  for  *type  of  codlno" 

Is 

'tiled  encojed^  For  the  up  order,  ft  k 

» ]»jch  thai  ^  liR^  or  only  iMt  of  the 

flr^  ixscie  word  shall  be  pieced  Ih  the  least  slgnKicani  bit  of  the  first  octet 

Subsecaiem  Mts  of  the  $ncl 

following  code  words  are  placed  In  ^e  dli^ctlon  of  more  signlflcarvt  bite 

In  the  Urst  md  Ibllowirig 

oc$els> 
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Por  Hie  <town  Ofider,  It  Is^^uofe  th^itheW  orontyiblt  <0  the  flm  cod^  ^i^o«l  shei  be  pteced  in  the  mm 
slgpiliBai^  l)lt  cf  the  first  odd^  Sii^equent  btts  of  the  first  and  fc^owing  oode  words  are  i^ced  in 
the  dlt^cJfett  of  lea^i  $l9iiific*irit 
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Annex  A  (normative) 
Amendments  and  corrigenda 

A.1  Amendments 

A.1.1       Amendments  to  the  base  standard 

The  amendments  applicable  to  this  DAP  includes  the  ISO  8613  -  Amendment  1:  1990.  This  amendment 
indudes  text  to  be  included  in  ISO  8613-1  as  the  following  annexes: 

a)  Annex  E:  Use  of  iSO/lEC  10021  (MOTIS)  to  interchange  documents  conforming  to  ISO  8613; 

b)  Annex  F:  Document  application  profile  proforma  and  notation; 

c)  Annex  G:  Conformance  testing  methodology; 

d)  Annex  H:  Recording  of  documents  conforming  to  ISO  8613  on  flexible  disk  cartridges 
conforming  to  ISO  9293. 

In  addition,  this  amendment  addresses  the  inclusion  of  the  ISO  8613  Technical  Corrigenda  1. 

This  DAP  does  not  include  the  following  features  of  the  amendment: 

a)  Addendum  on  security; 

b)  Addendum  on  styles; 

c)  Addendum  on  alternative  representation. 

Additionally,  this  DAP  includes  features  from  the  Tiled  Raster  Graphics  Addendum  to  ISO  8613-7,  ISO/lEC 
JTC1/SC18/WG5  901,  dated  September  l990^  ;aod:ll»:A£lditl^  m  Or<ter  Mapping  Acfdeodian  lo  CCITT 
T.417|iSO  8613-7,  l$0/IEC >ITCl/WO  3,  dat^       199t.  A  new  version  of  ISO  8613-7  which  also 
will  incorporate  the  Colour  Addendum  is  scheduled  to  be  issued  in  1992. 

A.2  Corrigenda 

A.2.1       Corrigenda  to  this  DAP 

Thoro  arc  no  oorrigonda  to  thio  DAP.The  prevails  version  of  the  doci«T)«rft  (Jittie  1 3^)  Imcorpora^  editoflaf 
and  t^hnical  changes  ^jproved  ^  m  M^fcli  1992  ODA  $ta  me^ltjg  as  we8  rifiir»or  $d8or!^  cljati3$$ 
shoved  at  tiie  Jum  ODA  £3G  meeting.  Teclinlcal  changes  ^uded:  addilion  d^CCITT  T.4  stqspott^ 
diang^basici       support  for  pa^e^e^  ami  pal  ^paidln0,  Bsmion  ^po^\cmmi  dlmendlor)  £$aiiir«9,  and 
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Iie^l0fii:«i^^|epi<ii9^  These  <;f«m^$  wm  made  to  $11^  more  <:kf^fMWfCXi^tifiP,  harmontee 
with  PAiS^itMii^^iMp^^^xciatlon  for  InforrnaUon  and  image  Managemem  (AliM)  requirements. 


TJiis  viM'^bi^         ciCK{umi»iif:;i:^^^  IddS)  InOcsporates  one'tei^ntiij  and  oliw  editorial  changes 

^i^^rmM  ^pte«itJ$f  1982  ODA  530  meet^g.  The  technical  change  wa$  to  add  object  Wentaiers  to 
fhm  *^fpe    ciodlng*  a^bute  to  suppoH:  both     and  dowit  btt  order  sequwvee^ 
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Annex  B  (informative) 
Recommended  practices 


B.I      Transfer  methods  for  ODA 


B.1.1       Conveyance  of  ODA  over  CCITT  X.400-1984 

This  recommendation  describes  how  ODA  body  parts  are  to  be  encoded  for  transmission  over  a  CCITT 
X.400-1984  service. 

An  ODA  body  part  is  encoded  as  OdaBodyPart  in  thie  definition  given  below: 


OdaBodyPart  ::=  SEQUENCE  {  OdaBodyPartParameters.  OdaData  } 
OdaBodyPartParameters  ::=  SET  { 
document-application-profile 

[0]  IMPLICIT  OBJECT  IDENTIF|ER, 
document-architecture-class 

[1]  IMPLICIT  INTEGER  { 
formatted  (0), 
processable  (1), 
formatted-processable  (2)  } 
OdaData  ::=     SEQUENCE  OF  Interchange-Data-Element 


NOTE  -  It  is  recommended  to  transfer  an  ODA  document  as  a  single  body  part  with  tag  12: 
Oda  [12]  IMPLICIT  OCTETSTRING 

The  content  of  the  octet  string  is  encoded  as  OdaBodyPart,  defined  above.  However,  this  is  out 

of  the  scope  of  this  profile. 


B.I  .2       Conveyance  of  ODA  over  FTAM 

This  recommendation  describes  the  Fie  TraBSfer,  Access*  and  UamagiBms^  <FTAM|  Document  Type  to  be 
used  for  minimal  storage  and  transfer  capabilities  of  ODA  data  streams.  It  is  recognized  that  enhanced 

capabilities  may  at  some  point  be  added. 

When  using  FTAM  to  transfer  an  ODA  file,  the  RAM-3,  "ISO  FTAM  Unstructured  Binary",  document  type 
should  be  specified.  However,  since  files  that  do  not  contain  ODA  data  streams  can  have  the  same 
document  type,  it  is  left  up  to  the  user  of  application  programs  that  remotely  access  files  using  FTAM  to 
know  that  a  given  file  contains  an  ODA  data  stream. 
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This  recommendation  provides  for  information  concerning  the  interchange  of  ODA  based  documents  with 
OOfisUrrtent  tmrtSafer  and  Mfi^^Utdtion  pTAM|  (Dooumont  Trancfor  and  Manipuiatlon)  protocols. 

DTAM  is  defined  in  the  T.430-Series  of  recommendations  and  is.  iil<e  ODA,  an  integral  part  of  the  T.400- 
Series  of  CCiTT  Recommendations  named  Open  Document  Architecture,  Transfer  and  Manipulation. 

The  T.520-Series  of  recommendations  contain  Communication  Application  Profiles  (CAP) .  Recommendation 
T.522  describes  the  Communication  Application  Profile  BT1  for  document  bull<  transfer.  Recommendation 
T.522  is  applicable  for  the  Office  Document  Format  Profile  (FOD)  published  in  this  ISP. 

NOTE  -  The  use  of  BT1  within  the  end-to-end  oriented  Telematic  Services  Telefax  4  and  Teletex  is  described 
in  7.1  of  Recommendation  T.561  and  7.1  of  Recommendation  T.562. 

B.1 .4       Conveyance  of  ODA  over  flexible  disks 

The  recommended  method  for  interchanging  ODA  documents  between  systems  by  the  exchange  of 
magnetically  recorded  Flexible  Disk  Cartridges  is  by  the  use  of  an  annex  to  ISO  8613-1  (to  be  published), 
Receding  of  Documents  Conforming  to  ISO  8613  on  Flexible  Cartridges  Conforming  to  ISO  9293.  This 
annex  provides  for  recording  each  ODA  document  as  a  separate  file  as  defined  by  ISO  9293,  Volume  and 
File  Structure  of  Flexible  Disk  Cartridges  for  Information  Interctiange. 

NOTE  -  Document  encoded  in  ODL  can  be  stored  such  that  each  SGML  ENTITY  is  recorded  in  a  separate 
file  or  in  the  case  of  an  SDIF  encoding,  the  file  can  be  stored  in  a  single  file. 

B.2     Interoperability  with  SGML  applications 

The  recommended  method  for  the  exchange  of  documents  between  Standard  Generalized  Markup 
Language  (ISO  8879,  SGML)  based  systems  and  systems  based  on  this  ODA  document  application  profile 
is  by  means  of  exchanging  a  document  representation  conforming  to  these  agreements  in  an  encoded  form 
of  the  SGML  language  known  as  the  Office  Document  Language  (ODL).  ODL  is  a  standardized  SGML 
application  for  representing  documents  conforming  to  the  ODA  base  standard.  Such  a  representation  can 
be  converted  into  the  Office  Document  Interchange  Format  (ODIF)  supported  by  this  document  application 
profile. 
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Annex  C  (informative) 

References  to  other  standards  and  registers 

CCITT  Recommendation  T.400  :  1988,  Introduction  to  Document  Arcliitecture,  Transfer  and  Manipulation; 

CCITT  Recommendation  T.411  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Introduction  and  General  Principles; 

CCITT  Recommendation  T.412  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Structures; 

CCITT  Recommendation  T.414  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format: 
Document  Profile; 

CCITT  Recommendation  T.415  :  1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format:  Open 
Document  Interchange  Format; 

CCITT  Recommendation  T.41 7  : 1988,  Open  Document  Architecture  (ODA)  and  Interchange  Format:  Raster 
Graphics  Content  Architecture; 

CCITT  Recommendation  T.503 : 1984,  Document  Application  Profile  for  the  Interchange  of  Group  4  Facsimile 
Documents; 

ISO  8571  : 1988,  Information  processing  systems  -  Open  Systems  Interconnection  -  File  transfer,  access  and 
management; 

ISO  9070  : 1990,  Information  processing  -  SGML  support  facilities  -  Registration  procedures  for  public  owner 
identifiers; 

ISO/TR  9573  :  1988,  Information  processing  -  SGML  technical  report  -  Techniques  for  using  SGML; 

ISO  10021  :  (to  be  published).  Information  processing  systems  -  Text  communication  -  Message  Oriented 
Text  Interchange  System; 

ISP  FOD26  :  (to  be  published),  Office  document  format  profile  for  the  interchange  of  enhanced  function 
mixed  content  documents  in  processable  and  formatted  forms; 

ISP  FOD36  :  (to  be  published).  Office  document  format  profile  for  the  interchange  of  extended  function 
mixed  content  documents  in  processable  and  formatted  forms; 

MIL-R-28002A  :  1990,  MILITARY  SPECIFICATION,  RASTER  GRAPHICS  REPRESENTATION  IN  BINARY 
FORMAT,  REQUIREMENTS  FOR. 
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Annex  D  (informative) 

Supplementary  information  on  attributes 


Table  D.I  -  Content  coding  attributes 


Attributes 

Basic  values 

Default  values 

Non-basic 
values 

Number-of-pels-per-line 

any  positive  integer 

None 

None 

Number-of-lines 

any  positive  integer 

None 

None 

Tiling-offset* 

(any  non-negative  integer 
<  512,  any  non-negative 
integer  <  512) 

(0,0) 

None 

Tile-types* 

T.6  encoded,  bitmap 
encoded,  null 
background,  null 
foreground^  T6  dnC<jddd  - 

Him 

T.6  encoded 

None 

Type-of-coding 

T.6  encoding  (untiled), 
bitmap  (untiled),  tiled 
encocfed^T,4 1D 
e«<»<in9i  T>4  2D 
encoding:,     »MX>dlng  - 
tm  {mm*  T<4  to 
<>nCCMilfftJf  -  *ftSB»  T*4  2D 
enccMing  ^  MSB 

T.6  encodingpili^ 
encoding  ** 

None 

Tutorial  Note  -  *  Only  used  if  "type  of  coding"  is  'tiled  encodecf 


T^<^l  s  specified:  kt  Ihe  documanH  ptcMd 


Table  D.2  -  Presentation  attributes 


Attributes 

Basic  values 

Default  values 

Non-basic  values 

Pel-path 

0,  90  deg 

0  deg 

180,  270  deg 

Line-progression 

270  deg 

270  deg 

90  deg 

Pel-spacing 

6  BMU  (200),  A  BMU 
(3e6)1Bt12^B,6,&*4va 

4  BMU  (300) 

Any  valueiiiiiiip 

ilii 

Clipping 

Two  Coordrfrjfite  Pairs 
(any  non-negative  integer, 
any  non-negative  integer) 

(0,0),  (N-1,  L-1) 

None 
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Table  D.3  -  Document  profile  attributes 


Attribute 

Class 

Permissible  values 

Specific-layout-structure 

m 

present 

Presentation-styles 

nm 

present 

Document-characteristics 

M 

Document-architecture-class 

m 

formatted 

Document-application-profile 

m 

{-  See  clause  8  for  a  definition  of  the 
permitted  values  for  this  attribute.  -} 

Content-architecture-classes 

m 

{282  72} 

Interchange-format-class 

m 

A 

ODA-version 

m 

ISO  8613,  1989-07 -04  19S1-12-31 

Document-architecture-defaults 

M 

Content-architecture-class 

m 

formatted  processable  raster  graphics 

Type-of-coding 

«m 

T.6  Eincoding;  (default)  Ttiled 
E|ncoding,  T-$  WCCMinS  ^ 

Page-dimensions 

nm 

See  list  in  table  1 ,  (Default  value  is  NA- 
A,  9240  X  13200  BMU) 

Medium-types 



nm 

See  list  in  table  1 ,  (Default  value  is  NA- 
A,  9240  X  13200  BMU) 

Page-position 

nm 

any  cooruineue  pair  wiinin  payo 

Raster-gr-content-defaults 

NM 

Pel-path 

nm 

0,  90,  180,  270  degrees  (0  is  normal 
default) 

Line-progression 

nm 

90,  270  degrees  (270  is  normal  default) 

Clipping 

nm 

any  coordinate  pair  within  page 

Pel-spacing 

nm 

6  BMU  (200  pole/in.)  or  <1  BMU  (300 

polc/in.),16>     8, «  S,  4,  a.  2»  f  BMU, 
(Normal  default  is  4  BMU) 

Spacing  Ratio 

nm 

Any  value 

Non-basic-doc-characteristics 

NM 

Page-dimensions 

nm 

See  table  1,  NA  F  through  NA  K,  roll 
p3por 

Medium-types 

nm 

See  table  1,  NAF  through  NA  K,  roll 

p3p0f 
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Table  D.3  -  Document  profile  attributes  (concluded) 


Attribute 

Class 

Permissible  values 

Raster-gr-preserrtation-features 

NM 

Pel-path 

nm 

180,  270  degrees 

Line-progression 

nm 

90  degrees 

Pel-spacing 

nm 

Any  value  except  6  BMU  (300  pele/in.) 
or  A  BMU  (300  pole/in.)  16,  12,  $, 

Document-management-attributes 

M 

Document  Reference 

m 

Any  string  of  characters 

The  following  notation  is  used  In  the  class  column  of  this  table: 
m   mandatory  attribute  nm  non-mandatory  attribute  d   defaultable  attribute 
Capital  letters  (M,  NM,  and  D)  are  used  for  groups  of  attributes. 
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Annex  £  (informative) 


ma  {1}  klenliSeck»iganiza6c»i  (3)  oiw  {t4}  ode 

ho  (1  j  Jdentlffed-orgsnizafton  (3)  oiw  (U)  odd 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Conformance  Testing  Special 
Interest  Group  (CTSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Editor's  Note  -  This  part  is  reserved  for  future  stable  Conformance  Testing  Agreements.  These  agreements 
may  be  found  in  the  aligned  part  of  the  Working  Implementation  Agreements  document.  When  these 
agreements  become  stable,  they  will  be  moved  into  Part  24. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Health  Care  Special  Interest  Group 
(HCSIG)  of  the  Open  Systems  Environment  Implementors'  Workshop  (OIW). 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  a  new 
part.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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found  in  the  aligned  part  of  the  Working  Implementation  Agreements  document.  When  these  agreements 
become  stable,  they  will  be  moved  into  Part  25. 
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This  document  records,  In  replacement  page  fornnat,  all  changes  to  stable  material  which  was  current 
(according  to  Version  and  Edition  number)  as  of  the  end  of  December  1991.  In  this  case,  that  would  be 
NIST  SP  500-202,  Version  5,  Edition  1.  By  following  the  instructions  below,  and  replacing  or  inserting  the 
indicated  pages,  text  will  be  created  which  reflects  the  current  status  of  relevant  stable  material  as  of 
March  13,  1992. 

If  there  are  fedNft$  or  strikeout  in  the  Table  of  Contents,  then  that  document  should  contain  the  replacement 
pages  for  March  1992.  THIS  INSERT  SET  SHOULD  BE  SAVED. 

The  following  table  gives  all  necessary  information.  Entries  in  the  first  column  Indicate  that  those  pages  are 
to  be  replaced  with  the  pages  referenced  in  the  second  column. 

The  instructions  below  are  given  by  Chapter  and  Page  number,  referring  to  NIST  SP  500-202.  The  changes 
made  are  indicated  by  redline  and  strikeout  on  the  pages  where  the  changes  occur,  and  all  the  replacement 
pages  are  dated  in  the  upper  right-hand  corner  for  easy  identification. 

Changes  on  replacement  pages  are  Errata  (technical,  alignment,  editorial,  or  other).  The  term  "other"  may 
include  addition  of  new  stable  functionality.  All  changes  apply  to  the  previous  version  and  edition. 
Replacements  reflect  the  following  types  of  changes: 

1 .  deletion  of  material  (otriko  out) 

2.  insertion  of  new  material  (redfinte-^tiaded  words  or  setttences),  and 

3.  replacement  of  old  text  with  new  text,  (cbrnbination  of  (1)  arid  (2)  above. 

Technical  errata  are  changes  from  implementor  experience  which  materially  affect  the  meaning  or  semantics 
of  a  section,  and  editorial  changes  do  not  change  semantics.  Alignment  changes  are  material  changes 
made  in  the  interest  of  international  harmonization  and  evolving  base  standards. 

In  general,  technical  errata  are  more  "severe"  than  editorial  errata,  and  alignment  errata  are  more  "severe" 
than  technical  errata.  If  a  particular  replacement  has  a  combination  of  errata,  the  most  "severe"  errata  will 
be  checked  in  the  replacement  page  table.  Readers  should  keep  in  mind  that  these  errata  may  be  further 
categorized  in  future  editions. 
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CHANGE  PAGES  TO  VERSION  5,  EDITION  1 
OUTPUT  FROM  THE  JUNE  1992  WORKSHOP 
ISSUED  SEPTEMBER  21,  1992 

SUPPLEMENT  TO  STABLE  IMPLEMENTATION  AGREEMENTS 
FOR  OPEN  SYSTEMS  INTERCONNECTION  PROTOCOLS 
NIST  SPECIAL  PUBLICATION  500-202 

This  document  records,  In  replacement  page  format,  all  changes  to  stable  material  which  was  current 
(according  to  Version  and  Edition  number)  as  of  the  end  of  March  1992.  In  this  case,  that  would  be  NIST 
SP  500-202,  Version  5,  Edition  1.    By  following  the  instructions  below,  and  replacing  or  inserting  the 
indicated  pages,  text  will  be  created  which  reflects  the  current  status  of  relevant  stable  material  as  of 
June  11,  1992. 

If  there  are  redHiie  or  strikeout  in  the  Table  of  Contents,  then  that  document  should  contain  the  replacement 
pages  for  June  1992.  THIS  INSERT  SET  SHOULD  BE  SAVED. 

The  following  table  gives  all  necessary  information.  Entries  in  the  first  column  indicate  that  those  pages  are 
to  be  replaced  with  the  pages  referenced  In  the  second  column. 

The  instructions  below  are  given  by  Chapter  and  Page  number,  referring  to  NIST  SP  500-202.  The  changes 
made  are  indicated  by  redline  and  strikeout  on  the  pages  where  the  changes  occur,  and  all  the  replacement 
pages  are  dated  in  the  upper  right-hand  corner  for  easy  identification. 

Changes  on  replacement  pages  are  Errata  (technical,  alignment,  editorial,  or  other).  The  term  "other"  may 
include  addition  of  new  stable  functionality.  All  changes  apply  to  the  previous  version  and  edition. 
Replacements  reflect  the  following  types  of  changes: 

1 .  deletion  of  material  (otriko  out) 

2.  insertion  of  new  material  (redline-shaded  words  or  sentences),  and 

3.  replacement  of  old  text  with  new  text,  (combination  of  (1)  and  (2)  above). 

Technical  errata  are  changes  from  implementor  experience  which  materially  affect  the  meaning  or  semantics 
of  a  section,  and  editorial  changes  do  not  change  semantics.  Alignment  changes  are  material  changes 
made  in  the  interest  of  international  harmonization  and  evolving  base  standards. 

In  general,  technical  errata  are  more  "severe"  than  editorial  errata,  and  alignment  errata  are  more  "severe" 
than  technical  errata.  If  a  particular  replacement  has  a  combination  of  errata,  the  most  "severe"  errata  will 
be  checked  in  the  replacement  page  table.  Readers  should  keep  in  mind  that  these  errata  may  be  further 
categorized  in  future  editions. 
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CHANGE  PAGES  TO  VERSION  5,  EDITION  1 
OUTPUT  FROM  THE  SEPTEMBER  1992  WORKSHOP 
ISSUED  DECEMBER  14,  1992 

SUPPLEMENT  TO  STABLE  IMPLEMENTATION  AGREEMENTS 
FOR  OPEN  SYSTEMS  INTERCONNECTION  PROTOCOLS 
NIST  SPECIAL  PUBLICATION  500-202 

This  document  records,  in  replacement  page  format,  all  changes  to  stable  material  which  was  current 
(according  to  Version  and  Edition  number)  as  of  the  end  of  June  1992.  In  this  case,  that  would  be  NIST 
SP  500-202,  Version  5,  Edition  1.   By  following  the  instructions  below,  and  replacing  or  inserting  the 
indicated  pages,  text  will  be  created  which  reflects  the  current  status  of  relevant  stable  material  as  of 
September  25,  1992. 

If  there  are  fiijlii  or  strikeout  in  the  Table  of  Contents,  then  that  document  should  contain  the  replacement 
pages  for  September  1992.  THIS  INSERT  SET  SHOULD  BE  SAVED. 

The  following  table  gives  all  necessary  information.  Entries  in  the  first  column  indicate  that  those  pages  are 
to  be  replaced  with  the  pages  referenced  in  the  second  column. 

The  instructions  below  are  given  by  Chapter  and  Page  number,  referring  to  NIST  SP  500-202.  The  changes 
made  are  indicated  by  redline  and  strikeout  on  the  pages  where  the  changes  occur,  and  all  the  replacement 
pages  are  dated  in  the  upper  right-hand  corner  for  easy  identification. 

Changes  on  replacement  pages  are  Errata  (technical,  alignment,  editorial,  or  other).  The  term  "other"  may 
include  addition  of  new  stable  functionality.  All  changes  apply  to  the  previous  version  and  edition. 
Replacements  reflect  the  following  types  of  changes: 

1 .  deletion  of  material  (strike  out) 

2.  insertion  of  new  material  (redline-shaded  words  or  sentences),  and 

3.  replacement  of  old  text  with  new  text,  (combination  of  (1)  and  (2)  above). 

Technical  errata  are  changes  from  implementor  experience  which  materially  affect  the  meaning  or  semantics 
of  a  section,  and  editorial  changes  do  not  change  semantics.  Alignment  changes  are  material  changes 
made  in  the  interest  of  international  harmonization  and  evolving  base  standards. 

In  general,  technical  errata  are  more  "severe"  than  editorial  errata,  and  alignment  errata  are  more  "severe" 
than  technical  errata.  If  a  particular  replacement  has  a  combination  of  errata,  the  most  "severe"  errata  will 
be  checked  in  the  replacement  page  table.  Readers  should  keep  in  mind  that  these  errata  may  be  further 
categorized  in  future  editions. 


I 
I 

I 


\ 


! 

i 
i 


DELETE  PAGE 
NUMBER 

INSERT  PAGE 
NUMBER 

TECHNICAL 

ALIGNMENT 

EDITORIAL 

OTHER 

Part  1 
Cover 

Part  1 
Cover 

X 

Part  1 
Foreword 

Part  1 
Foreword 

X 

Part  2 
Cover 

Part  2 
Cover 

X 

Part  2 
Foreword 

Part  2 
Foreword 

X 

Part  3 

Complete  Part 

Part  3 

Complete  Part 

X 

Part  4 
Cover 

Part  4 
Cover 

X 

Part  4 
Foreword 

Part  4 
Foreword 

X 

Parts 
Cover 

Parts 
Cover 

X 

Part  5 
Foreword 

Part  5 
Foreword 

X 

Part  6 
Cover 

Part  6 
Cover 

X 

Parte 
Foreword 

Parte 
Foreword 

X 

Part? 
Cover 

Part  ? 
Cover 

X 

Part? 
Foreword 

Part? 
Foreword 

X 

Part? 
TOC  v-vi 

Part? 
TOC  v-vi 

X 

Part? 
TOC  vii-viii 

Part? 
TOC  vii-viii 

X 

Part? 

Pages  31-32 

Part  ? 

Pages  31-32 

X 

Part? 
insert 

Pages  32-1- 
Blank 

X 

DELETE  PAGE 
NUMBER 

INSERT  PAGE 
NUMBER 

TECHNICAL 

ALIGNMENT 

EDITORIAL 

OTHER 

Part  7 

Pages  67-68 

Part  7 

Pages  67-68 

X 

Part  8 
Cover 

Part  8 
Cover 

X 

Part  8 
Foreword 

Part  8 
Foreword 

X 

Part  8 

Pages  19-20 

Part  8 

Pages  19-20 

X 

Part  9 
Cover 

Part  9 
Cover 

X 

Part  9 
Foreword 

Part  9 
Foreword 

X 

Part  10 
Cover 

Part  10 
Cover 

X 

Part  10 
Foreword 

Part  10 
Foreword 

X 

Part  11 
Cover 

Part  11 
Cover 

X 

Part  11 
Foreword 

Part  11 
Foreword 

X 

Part  12 
Cover 

Part  12 
Cover 

X 

Part  12 
Foreword 

Part  12 
Foreword 

X 

Part  12 
TOC 

Part  12 
TOC 

X 

Part  12 
Pages  1-4 

Part  12 
Pages  1-4 

X 

Part  12 
Pages  11-12 

Part  12 
Pages  11-12 

Part  13 
Cover 

Part  13 
Cover 

X 

Part  13 
Foreword 

Part  13 
Foreword 

X 

Part  14 
Cover 

Part  14 
Cover 

X 

Part  14 
Foreword 

Part  14 
Foreword 

X 

DELETE  PAGE 
NUMBER 

INSERT  PAGE 
NUMBER 

TECHNICAL 

ALIGNMENT 

EDITORIAL 

OTHER 

Part  14 
Pages  1-2 

Part  14 
Pages  1-2 

X 

Part  14 
Pages  3-4 

Part  14 
Pages  3-4 

X 

Part  15 

Complete  Part 

Part  15 

Complete  Part 

Part  16 

Complete  Part 

Part  16 

Complete  Part 

X 

Part  17 

Complete  Part 

Part  17 

Complete  Part 

X 



Part  18 

Complete  Part 

Part  18 

Complete  Part 

X 

Part  19 
Cover 

Part  19 
Cover 

X 



Part  19 
Foreword 

Part  19 
Foreword 

X 

Part  20 
Cover 

Part  20 
Cover 

X 

Part  20 
Foreword 

Part  20 
Foreword 

X 

Part  21 
Cover 

Part  21 
Cover 

X 

Part  21 
Foreword 

Part  21 
Foreword 

X 

Part  22 
Cover 

Part  22 
Cover 

X 

Part  22 
Foreword 

Part  22 
Foreword 

X 

Part  23 

Complete  Part 

Part  23 

Complete  Part 

X 

Part  24 
Cover 

Part  24 
Cover 

X 

Part  24 
Foreword 

Part  24 
Foreword 

X 

Part  25 
Cover 

Part  25 

oover 

X 

Part  25 
Foreword 

Part  25 
Foreword 

X 

llJ^kjM.  Technical  Publications 

Periodical 


Journal  of  Research  of  the  National  Institute  of  Standards  and  Technology- Reports  NIST 
research  and  development  in  those  disciplines  of  the  physical  and  engineering  sciences  in  which 
the  Institute  is  active.  These  include  physics,  chemistry,  engineering,  mathematics,  and  computer 
sciences. 

Papers  cover  a  broad  range  of  subjects,  with  major  emphasis  on  measurement  methodology  and 
the  basic  technology  underlying  standardization.  Also  included  from  time  to  time  are  survey 
articles  on  topics  closely  related  to  the  Institute's  technical  and  scientific  programs.  Issued  six 
times  a  year. 


Nonperiodicals 


Monographs -Major  contributions  to  the  technical  literature  on  various  subjects  related  to  the 
Institute's  scientific  and  technical  activities. 

Handbooks  —  Recommended  codes  of  engineering  and  industrial  practice  (including  safety  codes) 
developed  in  cooperation  with  interested  industries,  professional  organizations,  and  regulatory 
bodies. 

Special  Publications  —  Include  proceedings  of  conferences  sponsored  by  NIST,  NIST  annual 
reports,  and  other  special  publications  appropriate  to  this  grouping  such  as  wall  charts,  pocket 
cards,  and  bibliographies. 

Applied  Mathematics  Series  — Mathematical  tables,  manuals,  and  studies  of  special  interest  to 
physicists,  engineers,  chemists,  biologists,  mathematicians,  computer  programmers,  and  others 
engaged  in  scientific  and  technical  work. 

National  Standard  Reference  Data  Series  —  Provides  quantitative  data  on  the  physical  and  chemical 
properties  of  materials,  compiled  from  the  world's  literature  and  critically  evaluated.  Developed 
under  a  worldwide  program  coordinated  by  NIST  under  the  authority  of  the  National  Standard 
Data  Act  (Public  Law  90-396).  NOTE:  The  Journal  of  Physical  and  Chemical  Reference  Data 
(JPCRD)  is  published  bimonthly  for  NIST  by  the  American  Chemical  Society  (ACS)  and  the 
American  Institute  of  Physics  (AIP).  Subscriptions,  reprints,  and  supplements  are  available  from 
ACS,  1155  Sbcteenth  St.,  NW.,  Washington,  DC  20056. 

Building  Science  Series  —  Disseminates  technical  information  developed  at  the  Institute  on  building 
materials,  components,  systems,  and  whole  structures.  The  series  presents  research  results,  test 
methods,  and  performance  criteria  related  to  the  structural  and  environmental  functions  and  the 
durability  and  safety  characteristics  of  building  elements  and  systems. 

Technical  Notes  — Studies  or  reports  which  are  complete  in  themselves  but  restrictive  in  their 
treatment  of  a  subject.  Analogous  to  monographs  but  not  so  comprehensive  in  scope  or  definitive 
in  treatment  of  the  subject  area.  Often  serve  as  a  vehicle  for  final  reports  of  work  performed  at 
NIST  under  the  sponsorship  of  other  government  agencies. 

Voluntary  Product  Standards  —  Developed  under  procedures  published  by  the  Department  of 
Commerce  in  Part  10,  Title  15,  of  the  Code  of  Federal  Regulations.  The  standards  establish 
nationally  recognized  requirements  for  products,  and  provide  all  concerned  interests  with  a  basis 
for  common  understanding  of  the  characteristics  of  the  products.  NIST  administers  this  program 
as  a  supplement  to  the  activities  of  the  private  sector  standardizing  organizations. 
Consumer  Information  Series  —  Practical  information,  based  on  NIST  research  and  experience, 
covering  areas  of  interest  to  the  consumer.  Easily  understandable  language  and  illustrations 
provide  useful  background  knowledge  for  shopping  in  today's  technological  marketplace. 
Order  the  above  NlST  publications  from:  Superintendent  of  Documents,  Government  Printing  Office, 
Washington,  DC  20402. 

Order  the  following  NIST  publications  -  FIPS  and  NISTIRs-from  the  National  Technical  Information 
Service,  Springfield,  VA  22161. 

Federal  Information  Processing  Standards  Publications  (FIPS  PUB)  -  Publications  in  this  series 
collectively  constitute  the  Federal  Information  Processing  Standards  Register.  The  Register  serves 
as  the  official  source  of  information  in  the  Federal  Government  regarding  standards  issued  by 
NIST  pursuant  to  the  Federal  Property  and  Administrative  Services  Act  of  1949  as  amended, 
Public  Law  89-306  (79  Stat.  1127),  and  as  implemented  by  Executive  Order  11717  (38  FR  12315, 
dated  May  11,  1973)  and  Part  6  of  Title  15  CFR  (Code  of  Federal  Regulations). 
NIST  Interagency  Reports  (NISTIR)-A  special  series  of  interim  or  final  reports  on  work 
performed  by  NIST  for  outside  sponsors  (both  government  and  non-government).  In  general, 
initial  distribution  is  handled  by  the  sponsor;  public  distribution  is  by  the  National  Technical 
Information  Service,  Springfield,  VA  22161,  in  paper  copy  or  microfiche  form. 
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